From forrerj@ucs.orst.edu Sun Jun 02 23:12:01 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id XAA02444 for <HFSIG@TAPR.ORG>; Sun, 2 Jun 1996 23:11:58 -0500 (CDT)
Received: from p04.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA05223; Sun, 2 Jun 1996 21:11:47 -0700
Message-Id: <1.5.4.16.19960603053332.29172514@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 02 Jun 1996 21:33:32 -0800
To: HFSIG@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: QPSK BANDWIDTH ?

Hi all,

Could anyone please comment on the expected bandwidth for a DQPSK signal at
T bauds (or 2*T bits/sec) with raised cosine pulse shaping. 

I have been monitoring my QPSK signal using an FFT analyser program. My
modulator uses a root raised cosine response with x/sinx compensation with
alpha rolloff factor 0.2. While the QPSK signal is cycling though all its
possible bit patterns, I observe five peaks in the emitted spectrum as follows:

carrier at      0 dB,
+/- half T at  -6 dB,
+-       T at -14 dB.

Everything else is way down in the noise. From this observation, it appears
that the signal is contained into T Herz. Is this what is supposed to be
there? I am a little puzzled by the two components at +/- half T, also not
too clear whether I should or not use the x/sinx compensation in this case
and whether the rolloff factor is suitable. Theoretically, it looks OK on
simulations - The signal sounds nice and clean and melodic, but I may be
missing something.

Any comments and suggestions will be appreciated.

--Johan 



 

From BRYD@KIDD.CO.ZA Mon Jun 03 01:18:30 1996
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA13457 for <hfsig@tapr.org>; Mon, 3 Jun 1996 01:18:23 -0500 (CDT)
Received: from KIDD.CO.ZA by igw01 with smtp
	(Smail3.1.29.1 #3) id m0uQSxs-000P4BC; Mon, 3 Jun 96 08:18 GMT+0200
Received: from KenMail-Message_Server by KIDD.CO.ZA
	with Novell_GroupWise; Mon, 03 Jun 1996 08:21:26 +0200
Message-Id: <s1b2a086.016@KIDD.CO.ZA>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 03 Jun 1996 20:16:15 +0200
From: Danie Brynard <BRYD@KIDD.CO.ZA>
To: hfsig@tapr.org
Subject:  [HFSIG:1165] QPSK BANDWIDTH ? -Reply

Hi All. 

I have made some pic's (jpg format) of my EVM interface. Interesting
persons can email me for copies otherwise I will ask Johan to upload it to
the web page for hf signal processing

73 danie
BRYD@KIDD.CO.ZA


From mcdermot@rdxsunhost.aud.alcatel.com  Mon Jun 03 08:17:54 1996
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA24931 for <hfsig@tapr.org>; Mon, 3 Jun 1996 08:17:51 -0500 (CDT)
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1)
	id AA19420; Mon, 3 Jun 96 08:17:48 CDT
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM (4.1/SMI-4.1)
	id AA21315; Mon, 3 Jun 96 08:17:48 CDT
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA02940; Mon, 3 Jun 96 08:17:47 CDT
Date: Mon, 3 Jun 96 08:17:47 CDT
From: mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9606031317.AA02940@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:1165] QPSK BANDWIDTH ?

> Hi all,
>
> Could anyone please comment on the expected bandwidth for a DQPSK signal at
> T bauds (or 2*T bits/sec) with raised cosine pulse shaping.
>
> I have been monitoring my QPSK signal using an FFT analyser program. My
> modulator uses a root raised cosine response with x/sinx compensation with
> alpha rolloff factor 0.2. While the QPSK signal is cycling though all its
> possible bit patterns, I observe five peaks in the emitted spectrum as follows:
>
> carrier at      0 dB,
> +/- half T at  -6 dB,
> +-       T at -14 dB.
>
> Everything else is way down in the noise. From this observation, it appears
> that the signal is contained into T Herz. Is this what is supposed to be
> there? I am a little puzzled by the two components at +/- half T, also not
> too clear whether I should or not use the x/sinx compensation in this case
> and whether the rolloff factor is suitable. Theoretically, it looks OK on
> simulations - The signal sounds nice and clean and melodic, but I may be
> missing something.
>
> Any comments and suggestions will be appreciated.
>
> --Johan
>

	Johan: it is important that all measurements be done on a linear
channel -- ie: a class-C amplifier will significantly modify the spectrum
of a DQPSK signal.  A staggered-offset-QPSK (OQPSK, or SQPSK) signal will not
be widened as badly as straight QPSK, but both will widen when limited or
clipped.

	Secondly, it is important that a PRBS (of sufficient length)
be used to excite the filter, else you may get individual spectral lines
showing through.  If you have a repetitive pattern, the energy at the
discrete spectral lines may confuse things.  If your FFT is of short length,
and thus it truncates the PRBS pattern, this may also lead to measurement
error.  Additionally, windowing of the FFT, and compensation of amplitude
induced errors of the window may prove useful.

	I beleive that x/sinx compensation is correct if you are filtering
square-wavish pulses.  If you are filtering impulses, then compensation
is of course not necessary.

	You should have -3 dB at the +/- half T points of the TX output
spectrum regardless of the alpha factor, for a root-cosine transfer function
that has been properly compensated.  It then falls off faster past +/- 1/2T.
At +/- T there should be no output (filtered or not).  However, it is common
to have spectral leakage at +/- 1/T  due to feedthrough of the baud clock,
and some effort may be needed to track this down.  An alpha factor of 0.2
leads to some pretty wild ringing, and it's important to assure the
dynamic range of everything is preserved.  Also, a sufficient number of filter
taps is needed to have good out-of-band rejection at an alpha factor of 0.2,
I think about 33 taps were needed for my prototype in Excel to have adequate
out of band rejection.

	It sounds as though you are making excellent progress, and am glad
to see you using root-cosine filters so that the emitted spectrum will be
narrow.  The root-cosine filter on receive will help assure good noise
bandwidth of the receiver.  Incidentally, the noise bandwidth of a
root-cosine filter is independent of the alpha factor.


							- Tom, N5EG



------------------------------------------------+-----------------------------
 Tom McDermott					| "All opinions expressed
 Alcatel Network Systems, Inc.			| are my own, and do not
 mcdermot@aud.alcatel.com			| represent those of Alcatel
   [ ICC'96 Technical Program Secretary ]	| Network Systems, Inc."
   [   June 23-27, 1996, Dallas, Tx.    ]	|
------------------------------------------------+-----------------------------

From BRYD@KIDD.CO.ZA Mon Jun 03 08:29:20 1996
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA25439 for <hfsig@tapr.org>; Mon, 3 Jun 1996 08:28:59 -0500 (CDT)
Received: from KIDD.CO.ZA by igw01 with smtp
	(Smail3.1.29.1 #3) id m0uQZgm-000P5cC; Mon, 3 Jun 96 15:28 GMT+0200
Received: from KenMail-Message_Server by KIDD.CO.ZA
	with Novell_GroupWise; Mon, 03 Jun 1996 15:32:13 +0200
Message-Id: <s1b3057d.004@KIDD.CO.ZA>
X-Mailer: Novell GroupWise 4.1
Date: Tue, 04 Jun 1996 03:27:36 +0200
From: Danie Brynard <BRYD@KIDD.CO.ZA>
To: hfsig@tapr.org
Subject:  Center freq for rtty ?

By the way...

Why was such high tones selected for RTTY ? (2125Hz mark, 2295Hz
space)  My hf rig shows much better response at 800 to 1000Hz. Would
it not be better to implement the channel filters for a RTTY DSP modem
around say 800Hz ?

I am busy with a rtty dsp modem for the evm and is now wondering
about some of my earlier choices :-) From a DSP point of view would it
not be better to work around 800Hz ? I have used my PK232 with great
success in the past using my 500Hz CW filter on RTTY. 

danie zs6awk

From hardie@duke.usask.ca Mon Jun 03 11:36:58 1996
Received: from duke.usask.ca (duke.usask.ca [128.233.3.13]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA03637 for <hfsig@tapr.org>; Mon, 3 Jun 1996 11:36:52 -0500 (CDT)
Received: from localhost (hardie@localhost) by duke.usask.ca (8.7.3/8.7.3) with SMTP id KAA32561 for <hfsig@tapr.org>; Mon, 3 Jun 1996 10:36:38 -0600 (CST)
Date: Mon, 3 Jun 1996 10:36:38 -0600 (CST)
From: Pete Hardie <hardie@duke.usask.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:1168] Center freq for rtty ?
In-Reply-To: <s1b3057d.004@KIDD.CO.ZA>
Message-ID: <Pine.OSF.3.93.960603102921.3180A-100000@duke.usask.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 3 Jun 1996, Danie Brynard wrote:
> Why was such high tones selected for RTTY ? (2125Hz mark, 2295Hz
> space)

Back when I did a little RTTY with my KAM, I found that it could copy RTTY
much better if I used the LOwtones command. What this did was that instead
of using the 2125Hz Mark with the Space shifted above that, it used the
European "low_tones" in which the Space is 1275Hz and then the Mark is
shifted above that. I think I also had to use the INVert command.

So perhaps you could implement these low tones.

73 de Pete
ve5va.qrp@usask.ca


From FORRERJ@frl.orst.edu Mon Jun 03 12:28:14 1996
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA06309 for <hfsig@tapr.org>; Mon, 3 Jun 1996 12:28:10 -0500 (CDT)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU (8.6.9/8.6.9) with ESMTP id KAA04089 for <hfsig@tapr.org>; Mon, 3 Jun 1996 10:27:59 -0700
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    3 Jun 96 10:28:04 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 3 Jun 96 10:27:38 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 3 Jun 1996 10:27:36 -0800
Subject:       Re: [HFSIG:1167] Re: QPSK BANDWIDTH ?
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <58825D8058E@frl.orst.edu>

Hi Tom,

Thanks for the insight - I am learning a lot. Seems like I'm heading in the 
right direction.

For those that might be wondering what this is about; I have been 
exploring some of the materials in Tom's soon-to-be-released book on 
modem design. The section on pulse shaping is particularly good and 
includes extensive examples that one can play with using an Excel 
spreadsheet.

The pulses that need to be shaped are from the QPSK I/Q channels prior to 
modulation and they are indeed approximately square waves - I chose an alpha 
factor according to what I see being used in V32 modems - but I'll play 
with some of the other factor to see the effects. In my case the raised 
cosine filter order is 65 and the FFT program uses 4096 point FFTs that 
produces some 2 Hz resolution (I do assume that the program applies 
windows - it's the VE2IQ program).

Pulse shaping has introduced new problems with my clock and carrier 
acquisition algorithms, mainly because they are very much based 
on signal energy over a baud. Pulse shaping cleans the signal up to 
the extent that a lot more work is now needed to obtain and 
maintain reliable clock and carrier sync. I probably now need to add a 
scrambler to whiten the spectrum. What a lot of fun!

--Johan
 



From FORRERJ@frl.orst.edu Mon Jun 03 12:35:43 1996
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA06670 for <hfsig@tapr.org>; Mon, 3 Jun 1996 12:35:40 -0500 (CDT)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU (8.6.9/8.6.9) with ESMTP id KAA04348 for <hfsig@tapr.org>; Mon, 3 Jun 1996 10:35:33 -0700
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    3 Jun 96 10:35:38 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 3 Jun 96 10:35:13 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 3 Jun 1996 10:35:12 -0800
Subject:       Re: [HFSIG:1168] Center freq for rtty ?
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <58846303B36@frl.orst.edu>

Hi Danie,

The choice of 2125/2295 tone pair goes back a long way. It however, 
probably is not the best choice and you will find that the European standard 
specifies 1275/1445.

I dont know of any technical reason, besides IF and IF filters that makes 
one better than the other, besides some DSP algorithms that works better 
when you have more cycles of the waveform within a signaling element. You 
saw a lot of these kinds of technical arguments in the "old days" when 
folks used cassette tapes to store computer data.

Not sure this helps.

--Johan





From cbuttsch@slonet.org Mon Jun 03 14:40:02 1996
Received: from spork.callamer.com (cbuttsch@spork.callamer.com [199.74.141.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA12364 for <hfsig@tapr.org>; Mon, 3 Jun 1996 14:39:57 -0500 (CDT)
Received: from localhost (cbuttsch@localhost) by spork.callamer.com (8.7.5/8.7.3) with SMTP id MAA17100; Mon, 3 Jun 1996 12:37:45 -0700 (PDT)
Date: Mon, 3 Jun 1996 12:37:44 -0700 (PDT)
From: Clifford Buttschardt <cbuttsch@slonet.org>
X-Sender: cbuttsch@spork.callamer.com
To: Johan Forrer <FORRERJ@frl.orst.edu>
cc: hfsig@tapr.org
Subject: Re: [HFSIG:1170] Re: QPSK BANDWIDTH ?
In-Reply-To: <58825D8058E@frl.orst.edu>
Message-ID: <Pine.SOL.3.93.960603122853.14881C-100000@spork.callamer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Johan and Tom.  I am not sure from your message who Tom might be!  In
any case, I think that the use of 2125/2975 hertz for rtty eminated from
the first use of AFSK on sidband radios.  The idea here was to place the
tones as high in frequency as possible to avoid any harmonics from being
radiated.  The lower tones stand a chance that components will fall in the
passband.  There also were thoughts that the Q of 88 mHy inductors were
larger at the higher frequencies. (that's all we had to work with then!)
    Let me suggest that you check carefully with Bill DeCarle regarding
any programs of his supposedly written for windows.  It was our intent to
keep things as simple as possible and windows is as far from that concept
as could be imagined!  Cliff Buttschardt  W6HDO/K7RR

On Mon, 3 Jun 1996, Johan Forrer wrote:

> Hi Tom,
> 
> Thanks for the insight - I am learning a lot. Seems like I'm heading in the 
> right direction.
> 
> For those that might be wondering what this is about; I have been 
> exploring some of the materials in Tom's soon-to-be-released book on 
> modem design. The section on pulse shaping is particularly good and 
> includes extensive examples that one can play with using an Excel 
> spreadsheet.
> 
> The pulses that need to be shaped are from the QPSK I/Q channels prior to 
> modulation and they are indeed approximately square waves - I chose an alpha 
> factor according to what I see being used in V32 modems - but I'll play 
> with some of the other factor to see the effects. In my case the raised 
> cosine filter order is 65 and the FFT program uses 4096 point FFTs that 
> produces some 2 Hz resolution (I do assume that the program applies 
> windows - it's the VE2IQ program).
> 
> Pulse shaping has introduced new problems with my clock and carrier 
> acquisition algorithms, mainly because they are very much based 
> on signal energy over a baud. Pulse shaping cleans the signal up to 
> the extent that a lot more work is now needed to obtain and 
> maintain reliable clock and carrier sync. I probably now need to add a 
> scrambler to whiten the spectrum. What a lot of fun!
> 
> --Johan
>  
> 
> 
> 
> 

From FORRERJ@frl.orst.edu Mon Jun 03 15:12:36 1996
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id PAA13811 for <hfsig@tapr.org>; Mon, 3 Jun 1996 15:12:33 -0500 (CDT)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU (8.6.9/8.6.9) with ESMTP id NAA09281 for <hfsig@tapr.org>; Mon, 3 Jun 1996 13:12:30 -0700
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    3 Jun 96 13:12:35 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 3 Jun 96 13:12:30 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 3 Jun 1996 13:12:27 -0800
Subject:       Re: [HFSIG:1170] Re: QPSK BANDWIDTH ?
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <58AE5537E04@frl.orst.edu>

Hi Cliff,

Thanks for the note on the high tones - I also built those 88mH 
demodulators way back - had a lot of fun!

About "windows" - I trust you mean windows like in Hamming or Blackman-
Harris, not Microsoft? I use Bill's program under DOS and I suspect the 
anti-alias filter a little, otherwise, the program works reasonably well, 
just don't know whether he actually use a window, i.e., a raised cosine or 
such prior to the FFT. If not, its not a matter of life and death, just the 
spectrum is a little smeared due to Gibbs affects. That is what Tom 
McDermot, N5EG, was hinting at. He has written an excellent book on modems 
for the radio communications market, and I have had the pleasure to be a 
reviewer - the book will be out soon. 

Trust you doing OK? Hows the plans for moving coming along?

73's

--Johan

From karn@qualcomm.com Mon Jun 03 22:17:48 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA03345 for <hfsig@tapr.org>; Mon, 3 Jun 1996 22:17:44 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id UAA00621; Mon, 3 Jun 1996 20:17:05 -0700 (PDT)
Date: Mon, 3 Jun 1996 20:17:05 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606040317.UAA00621@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <1.5.4.16.19960603053332.29172514@ucs.orst.edu> (message from Johan Forrer on Sun, 2 Jun 1996 23:15:01 -0500 (CDT))
Subject: Re: [HFSIG:1165] QPSK BANDWIDTH ?

Johan,

Are you really testing with random data? From your description and
from your results, it sounds like you're using repeating patterns.

You need to use random data and average your results over a fairly
long interval.

Phil

From karn@qualcomm.com Mon Jun 03 22:24:12 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA03771 for <hfsig@tapr.org>; Mon, 3 Jun 1996 22:24:08 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id UAA00633; Mon, 3 Jun 1996 20:23:33 -0700 (PDT)
Date: Mon, 3 Jun 1996 20:23:33 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606040323.UAA00633@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <s1b3057d.004@KIDD.CO.ZA> (message from Danie Brynard on Mon, 3 Jun 1996 08:30:45 -0500 (CDT))
Subject: Re: [HFSIG:1168] Center freq for rtty ?

>Why was such high tones selected for RTTY ? (2125Hz mark, 2295Hz
>space)  My hf rig shows much better response at 800 to 1000Hz. Would
>it not be better to implement the channel filters for a RTTY DSP modem
>around say 800Hz ?

I suppose it depends on the radio. You should operate near the center
of whatever passband you have to avoid the phase distortion that is
invariably associated with sharp filters near cutoff.

Phil

From karn@qualcomm.com Mon Jun 03 22:29:07 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA03871 for <hfsig@tapr.org>; Mon, 3 Jun 1996 22:29:03 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id UAA00648; Mon, 3 Jun 1996 20:28:26 -0700 (PDT)
Date: Mon, 3 Jun 1996 20:28:26 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606040328.UAA00648@servo.qualcomm.com>
To: mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott)
CC: hfsig@tapr.org
In-reply-to: <9606031317.AA02940@eagle.aud.alcatel.com> (mcdermot@rdxsunhost.aud.alcatel.com)
Subject: Re: [HFSIG:1167] Re: QPSK BANDWIDTH ?

Tom,

Speaking of root raised cosine filters, would you be willing to design
a few for me for use in my SQPSK modem? I have the code for your book,
but I don't have Excel installed. I have the classic Parkes-McClellan
FORTRAN code, but it doesn't seem to be readily adaptable to an arbitrary
amplitude response.

I've been rewriting my modem code to use an arbitrary length FIR
filter.  At the moment I've kept the original 8-sample boxcar shape
that was inherent in my earlier explicit integrate-and-dump
implementation.

I'm using impulse signalling, so the transmit and receive filters can
be the same. Give me a alpha of about 0.5 or so (enough to keep the
energy at 1200 baud well within a typical SSB bandwidth). The baud rate
is 1200, the sampling rate is 9600. Will a 33 tap filter be sufficient?

Phil

From karn@qualcomm.com Mon Jun 03 22:47:51 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA04761 for <hfsig@tapr.org>; Mon, 3 Jun 1996 22:47:48 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id UAA00709; Mon, 3 Jun 1996 20:47:16 -0700 (PDT)
Date: Mon, 3 Jun 1996 20:47:16 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606040347.UAA00709@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <58825D8058E@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:1170] Re: QPSK BANDWIDTH ?

Johan,

You might consider the approach I've taken for symbol timing in my
satellite SQPSK (aka OQPSK) modem. Rather than extract symbol timing
from the data, I do it in a one-shot fashion at the beginning of every
packet with a modified Barker sync sequence. Since this is a packet
modem with a bounded packet length, I know that my one-shot estimate
should hold as long as the crystal clocks on the two ends are
reasonably accurate.

For carrier recovery, I also start with a one-shot estimate taken from
a carrier preamble, but because carrier frequency is more uncertain I
use the preamble estimate to seed an a posteriori 4-phase Costas loop
that updates the frequency from block to block.

The Costas loop used to work on raw symbols, but I just changed my
code so that once symbol timing is established, the incoming samples
are downconverted to DC, LP filtered, rate converted and complex
sampled at 2x the baud rate using a fixed LO downconversion frequency
derived from the carrier burst in the preamble.

Then the Costas loop only has to correct for the slow phase rotation
("slow" relative to the data rate) caused by any residual error in the
preamble frequency estimation (plus any doppler). Although complex
samples take more operations to process, I figure I probably save
overall from the rate conversion from 9600 samples/sec to 2400. And
I've already LP filtered, so I don't have to do that again.

I only need 2x sampling because of the I/Q symbol staggering; true
QPSK would only require 1x sampling once symbol timing is established.

Phil


From karn@qualcomm.com Mon Jun 03 23:04:14 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA06066 for <hfsig@tapr.org>; Mon, 3 Jun 1996 23:04:11 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id VAA00740; Mon, 3 Jun 1996 21:03:34 -0700 (PDT)
Date: Mon, 3 Jun 1996 21:03:34 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606040403.VAA00740@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <58846303B36@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:1171] Re: Center freq for rtty ?

>I dont know of any technical reason, besides IF and IF filters that makes 
>one better than the other, besides some DSP algorithms that works better 
>when you have more cycles of the waveform within a signaling element. You 

I've given this some thought recently, since I noticed some
interesting artifacts in my SQPSK modem receive constellation. It's
actually inherent in modulating a low frequency carrier with boxcar
pulses.

I had chosen a carrier frequency of 1600 Hz and a baud rate of 1200,
so there isn't an integral number of carrier cycles per symbol. So
when I did a boxcar integrate-and-dump, the I and Q channels aren't
perfectly orthogonal even when you have the carrier phase right. I
believe this was contributing to about a 1dB implementation loss in my
modem.

In the frequency domain, this effect shows up as the lower spectral
sidelobes (for unfiltered BPSK) "wrapping around" DC and aliasing back
up into the signal spectrum.

I verified my suspicions by testing at a carrier frequency of 2400 Hz,
exactly 2x the baud rate. It got rid of these spectral artifacts by
overlaying them in "safe" locations (or in the time domain, it ensured
an integral number of carrier cycles per symbol integration time.)

But this is not a practical solution for two reasons. First, you can't
guarantee that the receiver will get an incoming carrier at exactly
2400 bps, and secondly most SSB radios won't work that high anyway
(the first null above the carrier would occur at 3600 Hz, well outside
most SSB filters). I chose 1600 Hz in the first place precisely to
center the signal spectrum in a typical SSB filter bandwidth.

So I've been rewriting my modem code to include FIR filters in the I
and Q channels in both the transmit and receive data paths.  With the
appropriate filter response, the sidelobes should be low enough to
prevent spectral wraparound and aliasing. Or in the time domain, the
filter impulse should be small enough at the beginning and end of the
symbol time (where the carrier phase transition takes place) to
minimize the effect of the fractional carrier cycle in the sampled
filter output.

Of course, another fix would be even "sweeter" -- using two product
detectors in quadrature in the receiver and feeding complex audio
samples to the modem. This would allow the modem to distinguish easily
between positive and negative frequency components. Unfortunately,
most SSB transceivers don't have quadrature audio outputs...

Phil



From silbaugh@apci.net Mon Jun 03 23:27:33 1996
Received: from hilly.apci.net (root@hilly.apci.net [206.100.36.3]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id XAA06886 for <HFSIG@tapr.org>; Mon, 3 Jun 1996 23:27:30 -0500 (CDT)
Received: from dialup178.apci.net (dialup178.apci.net [206.100.36.178]) by hilly.apci.net (8.6.12/8.6.9) with SMTP id XAA22147; Mon, 3 Jun 1996 23:28:13 -0500
Date: Mon, 3 Jun 1996 23:28:13 -0500
Message-Id: <199606040428.XAA22147@hilly.apci.net>
X-Sender: silbaugh@apci.net
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Johan Forrer <forrerj@ucs.orst.edu>
From: "Eric E. Silbaugh" <silbaugh@apci.net>
Subject: Re: QPSK BANDWIDTH ?
Cc: HFSIG@tapr.org

Johan,

First let's ignore the differential encoding and raised 
cosine filetering.  Straight QPSK at T bauds/sec should
have the classic sin(x)/x squared power spectrum with a
main lobe width (null-to-null) of T Hz.  What you 
consider the 'occupied' bandwidth of this signal depends
on your definition; for now let's use the null-to-null
bandwidth.

Now add raised cosine filtering.  The frequency response 
of the RC filter (or composite of the RX and TX sqrt RC 
filters) will multiply the power spectrum of the original 
QPSK waveform to provide the resulting power spectrum.  
With a 0.2 rolloff, the ideal raised cosine spectrum will 
have a bandwidth of 1.2T Hz.  The percent excess bandwidth 
is equal to the rolloff factor.

In the real world your filter can only approximate the 
ideal RC impulse response.  Thus, the spectrum may not 
be identically zero beyond 0.6T Hz away from the carrier 
frequency.  If your filter is a good approximation there 
should be little 'splatter' beyond 0.6T Hz.

The previous discussion assumed the data symbols were
uncorrelated.  Differential encoding adds some memory; 
which means your symbols may not be uncorrelated anymore.
The power spectrum of a digitally modulated signal 
depends on the autocorrelation of the data.  (see 
J. G. Proakis, M. Salehi 'Communication Systems 
Engineering,' p.537, Prentice-Hall, 1994)  I think the 
effects of differential encoding on the spectrum should 
be minimal.  It certainly should not change the major 
features of the spectrum.

Sin(x)/x compensation effects should also be minimal, 
as long as your sampling rate is well above the 
Nyquist rate.  Again, compensation should not change
the major features of the spectrum.

All this is a very long way of saying a bandwidth of
about 1.2T Hz (almost T Hz) should be expected for 
your RC filtered DQPSK signal of T baud/sec.

I cannot explain the discrete components you noted. 
How do you create the signal you feed into the FFT?  
How many baud periods do you use in the FFT'd signal?
You will not get a good estimate of the average 
power spectrum from signals only a few baud long.  

To estimate the power spectrum with more detail I would 
create a signal from several tens or hundreds of random 
bits (independent) and FFT this long signal.  Yes this 
will require a long FFT, but it's just like turning down 
the resolution bandwidth of a spectrum analyzer.  The 
spectral resolution of the FFT is inversely proportional 
to the time duration of the signal you transform (longer
times mean finer resolution).

To estimate the average power spectrum you will probably 
want to use the same signal and compute the periodogram.  
Just average the FFTs of shorter segments of the signal.  
The FFT segments can overlap, but should probably be an 
integer number of bauds in length.  You will be trading 
off resolution for averaging.  See any good DSP book for 
details.

No clue as to the suitability of your choosen rolloff 
factor.  If it works I guess it's good enough!  A factor
of 0.2 seems to be a reasonable compromize from a 
bandwidth standpoint.  How much amplitude fluctuation 
in the time-domain does the filtering add?

Hope this helps, sorry for the bandwidth!


Eric, N2NNP

From forrerj@ucs.orst.edu Tue Jun 04 01:09:51 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA17355 for <HFSIG@TAPR.ORG>; Tue, 4 Jun 1996 01:09:10 -0500 (CDT)
Received: from p08.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA13543; Mon, 3 Jun 1996 23:08:10 -0700
Message-Id: <1.5.4.16.19960604073016.317f6a88@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 03 Jun 1996 23:30:16 -0800
To: HFSIG@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Root raised cosine pulse shaping.

Hi Tom,

Well ... After fixing a killer bug, the root raised cosine pulse shaping now
works like it is supposed to. The nicest, tightest constellation points that
I have seen thus far and no problem with clock or carrier extraction either.
Very nice eye patterns - I still have to implement pulse shaping filters in
the receiver to gain all the good benefits due to bandwidth reduction. I am
getting excellent results with a rolloff factor of 0.6.

Thanks for all the good hints.

--Johan  

From BRYD@KIDD.CO.ZA Tue Jun 04 01:12:50 1996
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA17391 for <hfsig@tapr.org>; Tue, 4 Jun 1996 01:12:47 -0500 (CDT)
Received: from KIDD.CO.ZA by igw01 with smtp
	(Smail3.1.29.1 #3) id m0uQpMC-000P9BC; Tue, 4 Jun 96 08:12 GMT+0200
Received: from KenMail-Message_Server by KIDD.CO.ZA
	with Novell_GroupWise; Tue, 04 Jun 1996 08:16:00 +0200
Message-Id: <s1b3f0c0.001@KIDD.CO.ZA>
X-Mailer: Novell GroupWise 4.1
Date: Tue, 04 Jun 1996 20:08:03 +0200
From: Danie Brynard <BRYD@KIDD.CO.ZA>
To: hfsig@tapr.org
Subject:  [HFSIG:1171] Re: Center freq for rtty ? -Reply

...besides some DSP algorithms that works better  when you have more
cycles of the waveform within a signaling element.....

I see. Well I will try to implement both and see if there are any practical
differences. I noted that Dave W3HCF is also using the high tones in his
DSP-93 implementation. Dave any comments from your side ?


73 Danie zs6awk


From karn@qualcomm.com Tue Jun 04 01:33:29 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA18009 for <hfsig@tapr.org>; Tue, 4 Jun 1996 01:33:26 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id XAA01122; Mon, 3 Jun 1996 23:32:54 -0700 (PDT)
Date: Mon, 3 Jun 1996 23:32:54 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606040632.XAA01122@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199606040428.XAA22147@hilly.apci.net> (silbaugh@apci.net)
Subject: Re: [HFSIG:1179] Re: QPSK BANDWIDTH ?

Eric,

An excellent writeup. One nit:

>cosine filetering.  Straight QPSK at T bauds/sec should
>have the classic sin(x)/x squared power spectrum with a
>main lobe width (null-to-null) of T Hz.  What you 

Shouldn't that be 2T Hz from null to null? E.g., a 1200 baud (2400
bps) QPSK signal with carrier at 1600 Hz would have first nulls at 400
Hz and 2800 Hz.

Those damn factors of 2 are so easy to get wrong, especially when some
of the textbooks talk about bits per sec and others talk about baud (2
bits/sym for QPSK)...

Phil

From JSANFORD@INFI.NET Tue Jun 04 06:02:05 1996
Received: from mh004.infi.net (mailhost.infi.net [205.219.238.95]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id GAA24677 for <hfsig@tapr.org>; Tue, 4 Jun 1996 06:02:03 -0500 (CDT)
Received: from pa1dsp21.orf.infi.net by mh004.infi.net with SMTP 
	(Infinet-S-3.3) id HAA13762; Tue, 4 Jun 1996 07:01:28 -0400 (EDT)
Message-Id: <199606041101.HAA13762@mh004.infi.net>
X-Sender: jsanford@infi.net
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 04 Jun 1996 07:02:15 -0400
To: hfsig@tapr.org
From: Jim Sanford <JSANFORD@INFI.NET>
Subject: Re: [HFSIG:1182] Re: QPSK BANDWIDTH ?

Phil:
Have enjoyed following all the threads you're into . . .

A couple of points:
        1.  For what platform are you doing the OQPSK
satellite modem?  I have 2 dsp-12's and would love to
beta test . . .
        2.  You made a comment about quadrature outputs
from SSB receivers being nice but not available.  I believe
they will be, SOON.  I'm working on a design using 
Analog Devices DDS's, Mini circuits DBM's, and Maxim's
quadrature modulators/demodulators.  This thing will initally
be for HF, but easily mixed/redesigned for vhf/uhf.  
The plummeting cost of the silicon is making this cheaper 
by the day.  

Intend to initally send I and Q to a "stereo" sound card for
easy playing with the DSP, but baseband bandwidth on the
Maxim demods is large enough that the design will not be 
limited to audio.  Will gladly share details with you, when
the prototype is done.  Believe cost will be $100 or so for
the whole works.

This business is getting terribly exciting -- believe we are on
the threshold of some great capabilities at significantly lower
prices than Icom, et al, would have us believe.  Thanks for all
you've done for the state-of-the-art.

73, Jim
wb4gcs@amsat.org

>
>Those damn factors of 2 are so easy to get wrong, especially when some
>of the textbooks talk about bits per sec and others talk about baud (2
>bits/sym for QPSK)...
>
        AMEN!!!!!!!

>Phil
>
>
>

From ssykes@ns2.emirates.net.ae Tue Jun 04 07:36:14 1996
Received: from ns2.emirates.net.ae (ns2.emirates.net.ae [194.170.1.7]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA27539 for <hfsig@tapr.org>; Tue, 4 Jun 1996 07:36:07 -0500 (CDT)
Received: from csb059.emirates.net.ae by ns2.emirates.net.ae (5.x/SMI-SVR495081401)
	id AA22662; Tue, 4 Jun 1996 16:35:50 +0400
Received: by csb059.emirates.net.ae with Microsoft Mail
	id <01BB5233.827F2140@csb059.emirates.net.ae>; Tue, 4 Jun 1996 16:33:06 +-400
Message-Id: <01BB5233.827F2140@csb059.emirates.net.ae>
From: Stephan Sykes <ssykes@ns2.emirates.net.ae>
To: "'hfsig@tapr.org'" <hfsig@tapr.org>
Subject: RE: [HFSIG:1168] Center freq for rtty ?
Date: Tue, 4 Jun 1996 16:25:54 +-400
Encoding: 29 TEXT, 59 UUENCODE
X-Ms-Attachment: WINMAIL.DAT 0 00-00-1980 00:00

I was told that the reason for the high tones was to place the harmonics of 
the tone outside of the IF filter bandwidth.  Improved filters and DSP make 
this unnecessary now.

Steve Sykes
KD2OM/A61AA

----------
From: 	Danie Brynard[SMTP:BRYD@kidd.co.za]
Sent: 	Monday, June 03, 1996 12:30 PM
To: 	hfsig@tapr.org
Subject: 	[HFSIG:1168] Center freq for rtty ?

By the way...

Why was such high tones selected for RTTY ? (2125Hz mark, 2295Hz
space)  My hf rig shows much better response at 800 to 1000Hz. Would
it not be better to implement the channel filters for a RTTY DSP modem
around say 800Hz ?

I am busy with a rtty dsp modem for the evm and is now wondering
about some of my earlier choices :-) From a DSP point of view would it
not be better to work around 800Hz ? I have used my PK232 with great
success in the past using my 500Hz CW filter on RTTY.

danie zs6awk
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From LANIER.R.A-@smtpgty.bwi.wec.com  Tue Jun 04 08:44:53 1996
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA29742 for <hfsig@tapr.org>; Tue, 4 Jun 1996 08:44:41 -0500 (CDT)
Received: from smtpgty.bwi.wec.com by tron.bwi.wec.com; (5.65/1.1.8.2/31May95-0229PM)
	id AA19449; Tue, 4 Jun 1996 09:42:44 -0400
Received: from ccMail by smtpgty.bwi.wec.com
  (IMA Internet Exchange 2.0 Enterprise) id 1B43D890; Tue, 4 Jun 96 09:43:37 -0400
Mime-Version: 1.0
Date: Tue, 4 Jun 1996 09:43:15 -0400
Message-Id: <1B43D890.1858@smtpgty.bwi.wec.com>
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-)
Subject: Re: [HFSIG:1156] Re: DSP for Linux (was: Modem audio sample)
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     Johan,
     
     I would interested in the URLs you are speaking about. Also, what is 
     the "size" of the box you are refering to?
     
     Tony,  KE4ATO


______________________________ Reply Separator _________________________________
Subject: [HFSIG:1156] Re: DSP for Linux (was: Modem audio sample)
Author:  hfsig@tapr.org at BALT.SMTP
Date:    5/23/96 9:02 PM


Hi Steve,
     
Another gem for Linux is Matcom; its a Matlab to C++ translator. Then there 
is Octave, which is a Matlab look-alike. Of course this software will only 
mean something to you if you are familiar with Matlab. Matlab allows for 
pretty sophisticated DSP evaluation and simulation. Also don't forget about 
Ptolemy - really nice but you need a fairly big Linux box to use it.
     
I don't have the URL's available at the moment, but can let you know if 
there is interest.
     
--Johan
     
At 01:55 PM 5/23/96 -0500, you wrote: 
>At 07:22 AM 5/23/96 -0500, you wrote: 
>>     Steve,
>>     
>>     Where do you find this great stuff??? 
>
>The best way to keep up with what's new with Linux is to read the 
>comp.os.linux.announce newsgroup.  There's also a web site that archives 
>them, the URL is http://www.cs.helsinki.fi/%7Ewirzeniu/linux/cola.html. 
>
>Otherwise, I don't watch a lot of TV.  I'd much rather read and experiment :-).
>
>73,
>
> - Steve, N7HPR
>
>srbible@gnatnet.net
>n7hpr@amsat.org
>n7hpr@tapr.org
>
>
     

From FORRERJ@frl.orst.edu Tue Jun 04 10:36:46 1996
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA05172 for <hfsig@tapr.org>; Tue, 4 Jun 1996 10:36:44 -0500 (CDT)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU (8.6.9/8.6.9) with ESMTP id IAA29269 for <hfsig@tapr.org>; Tue, 4 Jun 1996 08:36:41 -0700
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    4 Jun 96 08:36:46 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 4 Jun 96 08:36:35 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 4 Jun 1996 08:36:30 -0800
Subject:       Re: [HFSIG:1177] Re: QPSK BANDWIDTH ?
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <59E4CAB540F@frl.orst.edu>

Tom, Phil and Eric,

Much thanks for the excellent ideas and feedback. 

I do suspect that some of the spectral lines I'm seeing with my QPSK 
signal is due to the nature of the cyclic patters that is being sent. I'll 
work on a PRBS generator as suggested.

Clock and carrier extraction is a fascinating subject and I'll certainly 
look at Phil's ideas. For this HF modem, the symbol rate is so low that 
FFT's and all sort of things alike may be put to good use, and 
I'll get to that shortly. The main thing though is that HF is not too 
friendly to true synchronous detection methods - the key to success is to go 
for robustness in algorithm design. I think I have some ideas based on 
robustness (in the statistical sense) that seem work reasonably well, 
but need to be put through the wringer. 

I have been looking at epoch synch methods but was seeing enough drift even 
with two similar sound cards over a few seconds of signal. However, over a 
frame duration of a second or two, I suspect epoch sync may just work out 
fine.

Keep up the good work.

--Johan





From forrerj@ucs.orst.edu Tue Jun 04 10:50:48 1996
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA05759 for <hfsig@tapr.org>; Tue, 4 Jun 1996 10:50:44 -0500 (CDT)
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA02943; Tue, 4 Jun 1996 08:50:37 -0700
Date: Tue, 4 Jun 1996 08:50:37 -0700 (PDT)
From: Johan Forrer <forrerj@ucs.orst.edu>
To: hfsig@tapr.org
Subject: Re: [HFSIG:1183] Re: QPSK BANDWIDTH ?
In-Reply-To: <199606041101.HAA13762@mh004.infi.net>
Message-Id: <Pine.OSF.3.91.960604084018.15342A-100000@ucs.orst.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Jim,

Sounds interesting. Would you care to elaborate more?

I am sort of midway in a project building a VHF/UHF digital receiver for 
satellite work. It uses a CATV tuner for the RF front-end which has a 45MHz 
IF, 20 MHz A/D fed into a Harris DDC that feeds I/Q outputs into a stereo 
CODEC connected to a EZ-kit (ADSP-2181). I use an AD7008 DSS and a PLL for 
frequency control. 

I thought I would stay away from HF for a while until I learn a bit more 
about the RF digital dynamic range, AGC, and it's affects. Guess there is a 
lot to learn.


On Tue, 4 Jun 1996, Jim Sanford wrote:

> Phil:
> Have enjoyed following all the threads you're into . . .
> 
> A couple of points:
>         1.  For what platform are you doing the OQPSK
> satellite modem?  I have 2 dsp-12's and would love to
> beta test . . .
>         2.  You made a comment about quadrature outputs
> from SSB receivers being nice but not available.  I believe
> they will be, SOON.  I'm working on a design using 
> Analog Devices DDS's, Mini circuits DBM's, and Maxim's
> quadrature modulators/demodulators.  This thing will initally
> be for HF, but easily mixed/redesigned for vhf/uhf.  
> The plummeting cost of the silicon is making this cheaper 
> by the day.  

I would be interested to see what sideband rejection youre going to get. 
Don't be dissapointed if it's only about 40 dB.

 
> > Intend to initally send I and Q to a "stereo" sound card for
> easy playing with the DSP, but baseband bandwidth on the
> Maxim demods is large enough that the design will not be 
> limited to audio.  Will gladly share details with you, when
> the prototype is done.  Believe cost will be $100 or so for
> the whole works.
> 
> This business is getting terribly exciting -- believe we are on
> the threshold of some great capabilities at significantly lower
> prices than Icom, et al, would have us believe.  Thanks for al

--Johan, KC7WW

From dibene@VNET.IBM.COM Tue Jun 04 10:58:13 1996
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA05916 for <hfsig@tapr.org>; Tue, 4 Jun 1996 10:58:07 -0500 (CDT)
Message-Id: <199606041558.KAA05916@tapr.org>
Received: from ROMVMNIC by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8939;
   Tue, 04 Jun 96 11:57:49 EDT
Date: Tue, 4 Jun 96 17:55:39 EDT
From: "Alberto di Bene (xx39-2-596.25744)" <dibene@VNET.IBM.COM>
To: hfsig@tapr.org
Subject: Tom's books

>  For those that might be wondering what this is about; I have been
>  exploring some of the materials in Tom's soon-to-be-released book on
>  modem design. The section on pulse shaping is particularly good and

 Now you got me curious... any chance to have the title and ISBN of that
 book ? Thanks.

 73 de
 Alberto di Bene,  I2PHD

From cbuttsch@slonet.org Tue Jun 04 12:37:32 1996
Received: from spork.callamer.com (cbuttsch@spork.callamer.com [199.74.141.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA09926 for <hfsig@tapr.org>; Tue, 4 Jun 1996 12:36:56 -0500 (CDT)
Received: from localhost (cbuttsch@localhost) by spork.callamer.com (8.7.5/8.7.3) with SMTP id KAA22180; Tue, 4 Jun 1996 10:33:44 -0700 (PDT)
Date: Tue, 4 Jun 1996 10:33:42 -0700 (PDT)
From: Clifford Buttschardt <cbuttsch@slonet.org>
X-Sender: cbuttsch@spork.callamer.com
To: Stephan Sykes <ssykes@ns2.emirates.net.ae>
cc: Bill DeCarle <bill@ietc.ca>, hfsig@tapr.org
Subject: Re: [HFSIG:1184] RE: Center freq for rtty
In-Reply-To: <01BB5233.827F2140@csb059.emirates.net.ae>
Message-ID: <Pine.SOL.3.93.960604102455.17919D-100000@spork.callamer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

HI All.  I was one of probably many that indicated that the high tones
were used to keep harmonics down when using AFSK in SSB rig.  Indeed,
nowdays there is no reason to use such high tones and commercially, those
higher tones are obsolete!  We used such high frequencies as we simply
duplicated telephone channel filters in which 3 KHz was the upper limit.
Not a one of us knew enough about fileter design to change the system!
     I fully concer with the use of 800 Hz as a center frequency.  All of
Bill DeCarles work is centered there as is all my filter designs.  It
seems a good selection although a short time ago I was thumping for 500
Hertz as it would have make synthesizer design simpler...I lost!!
    Danie- I have no way of knowing what you said in the Winmail portion
of your note.  Can't cope with that!  sorry  Cliff Buttschardt W6HDO/K7RR

On Tue, 4 Jun 1996, Stephan Sykes wrote:

> I was told that the reason for the high tones was to place the harmonics of 
> the tone outside of the IF filter bandwidth.  Improved filters and DSP make 
> this unnecessary now.
> 
> Steve Sykes
> KD2OM/A61AA
> 
> ----------
> From: 	Danie Brynard[SMTP:BRYD@kidd.co.za]
> Sent: 	Monday, June 03, 1996 12:30 PM
> To: 	hfsig@tapr.org
> Subject: 	[HFSIG:1168] Center freq for rtty ?
> 
> By the way...
> 
> Why was such high tones selected for RTTY ? (2125Hz mark, 2295Hz
> space)  My hf rig shows much better response at 800 to 1000Hz. Would
> it not be better to implement the channel filters for a RTTY DSP modem
> around say 800Hz ?
> 
> I am busy with a rtty dsp modem for the evm and is now wondering
> about some of my earlier choices :-) From a DSP point of view would it
> not be better to work around 800Hz ? I have used my PK232 with great
> success in the past using my 500Hz CW filter on RTTY.
> 
> danie zs6awk
> 
> 
> 
> 
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From karn@qualcomm.com Tue Jun 04 15:07:53 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA15704 for <hfsig@tapr.org>; Tue, 4 Jun 1996 15:07:50 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id NAA10211; Tue, 4 Jun 1996 13:07:12 -0700 (PDT)
Date: Tue, 4 Jun 1996 13:07:12 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606042007.NAA10211@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199606041101.HAA13762@mh004.infi.net> (message from Jim Sanford on Tue, 4 Jun 1996 06:10:36 -0500 (CDT))
Subject: Re: [HFSIG:1183] Re: QPSK BANDWIDTH ?

>        1.  For what platform are you doing the OQPSK
>satellite modem?  I have 2 dsp-12's and would love to
>beta test . . .

The platform is a generic 486 or Pentium PC running my KA9Q NOS TCP/IP
package. The modem will be integrated in as an interface driver for a
SoundBlaster 16 card *without* any special DSP chips.

Your work with the 'digital friendly' receiver sounds very
interesting!  I do hope that whatever you come up with can be easily
replicated by the average amateur -- in my experience, that's where
many promising amateur hardware projects fall down. It's the main
reason I've become so interested in using mass-market PC hardware to
the greatest possible extent, doing everything else in software. But
there are definite limits to the available hardware (particularly in
the radios) so your work is most welcome. I agree, this stuff ought
not to be as expensive and complicated as it seems to be.

At Dayton I looked at some of the companies selling after-market
crystal filters for commercial SSB transceivers with an eye toward
modifying them for wider baseband bandwidths. Ideally I'd like a ~20
KHz bandwidth so I could fully utilize the A/D bandwidth of a PC sound
card. I could even create a new "IF" at, say, 10 KHz and do my final
"product detection" in DSP software.

The guy behind the Fox-Tango table, being used to selling very sharp
and narrow crystal filters for HF contest and DX use, couldn't figure
out why in the world I would want to make my rig go *wider*. Ah, the
"narrowband mindset" seems pretty well entrenched. :-)

Phil


From LAITINEN@ESHOP.UOREGON.EDU Tue Jun 04 15:49:09 1996
Received: from ESHOP.UOREGON.EDU (eshop.uoregon.edu [128.223.94.14]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id PAA17008 for <hfsig@tapr.org>; Tue, 4 Jun 1996 15:49:05 -0500 (CDT)
Date:    Sun, 4 Jun 1995 13:48:40 -0700 (PDT)
From: LAITINEN@ESHOP.UOREGON.EDU
Message-Id: <950604134841.b9b@ESHOP.UOREGON.EDU>
Subject: RE: [HFSIG:1189] RE: Center freq for rtty
To: hfsig@tapr.org
X-Vmsmail-To: SMTP%"hfsig@tapr.org"

Gee, I thought that the use of 2125/2975 Hz for AFSK tones in the old 
days was related to running AFSK RATT on 2-meters "AM" (and then 
eventually FM).  Tuning the AFSK generator and TU filters to the proper
frequencies was done using standard tuning forks and lisajous (spelling?)
patterns on an oscilloscope.  Standard landline VFCT (Voice Freq Carrier
Telegraph) systems (as I recall) were set up with 85-Hz channels and the 
tools (i.e., tuning forks) were around for tuning such things...  Thus the
harmonic relationships of the old 2125/2975 tones to these tuning fork 
standards were important...  

My first 2-meter RATT setup used an ARC-5/T-23 surplus aircraft radio 
modulated by an Eico 730K modulator.  The RATT gear was a Model 19 with a 
W2JAV TU (the one with four neon bulbs on the front)....  The receiver was
the 417A converter that was popular in the early 1960's for Project OSCAR...

Larry, WA6JYJ/7

From wd5ivd@tapr.org Tue Jun 04 20:49:23 1996
Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id UAA29453 for hfsig@tapr.org; Tue, 4 Jun 1996 20:49:22 -0500 (CDT)
From: Greg Jones <wd5ivd@tapr.org>
Message-Id: <199606050149.UAA29453@tapr.org>
Subject: Re: [HFSIG:1188] Tom's books
To: hfsig@tapr.org
Date: Tue, 4 Jun 1996 20:49:22 -0500 (CDT)
In-Reply-To: <199606041558.KAA05916@tapr.org> from "Alberto di Bene" at Jun 4, 96 11:10:08 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Title: Wireless Digital Communications: Design and Theory
By: Tom McDermott, N5EG
ISBN: 0-9644707-2-1

Anticipated price will be $39.00

With luck it will be available from TAPR the end of August/first of Sept.
Tom is currently doing small technical corrections and the proof-reader is
working over grammer issues.  I get those elemtns and then with luck we go
to thew e printers.

I think there is a web page already on the tapr web server under
publications.  If it isn't there -- then I have it ready, but haven't put it
up yet,.  Has a complete index...that is if it is up.

This has been a year and a half project.  Will be glad to get it finsihed.

Cheers - Greg, WD5IVD

> 
> >  For those that might be wondering what this is about; I have been
> >  exploring some of the materials in Tom's soon-to-be-released book on
> >  modem design. The section on pulse shaping is particularly good and
> 
>  Now you got me curious... any chance to have the title and ISBN of that
>  book ? Thanks.
> 
>  73 de
>  Alberto di Bene,  I2PHD
> 
> 

From BRYD@KIDD.CO.ZA Wed Jun 05 01:13:35 1996
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA14915 for <hfsig@tapr.org>; Wed, 5 Jun 1996 01:13:27 -0500 (CDT)
Received: from KIDD.CO.ZA by igw01 with smtp
	(Smail3.1.29.1 #3) id m0uRBbI-000PEZC; Wed, 5 Jun 96 07:57 GMT+0200
Received: from KenMail-Message_Server by KIDD.CO.ZA
	with Novell_GroupWise; Wed, 05 Jun 1996 08:01:08 +0200
Message-Id: <s1b53ec4.049@KIDD.CO.ZA>
X-Mailer: Novell GroupWise 4.1
Date: Wed, 05 Jun 1996 19:56:05 +0200
From: Danie Brynard <BRYD@KIDD.CO.ZA>
To: hfsig@tapr.org
Subject:  [HFSIG:1191] RE: Center freq for rtty -Reply

Larry now that is interesting. Thanks for the bit of history.

danie 


From LANIER.R.A-@smtpgty.bwi.wec.com  Wed Jun 05 10:56:50 1996
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA02516 for <hfsig@tapr.org>; Wed, 5 Jun 1996 10:56:48 -0500 (CDT)
Received: from smtpgty.bwi.wec.com by tron.bwi.wec.com; (5.65/1.1.8.2/31May95-0229PM)
	id AA04947; Wed, 5 Jun 1996 11:53:42 -0400
Received: from ccMail by smtpgty.bwi.wec.com
  (IMA Internet Exchange 2.0 Enterprise) id 1B5ADB10; Wed, 5 Jun 96 11:54:25 -0400
Mime-Version: 1.0
Date: Wed, 5 Jun 1996 09:48:54 -0400
Message-Id: <1B5ADB10.1858@smtpgty.bwi.wec.com>
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-)
Subject: Sine wave PROM
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     I am trying to locate information on generating sine wave data for a 
     EEPROM. I had an article (Radio Electronics) describing this by using 
     a C program to generate the data. However, I can't find the article.
     
     Can someone help with this problem?
     
     73s de
     Tony,  KE4ATO

From silbaugh@apci.net Wed Jun 05 22:39:35 1996
Received: from hilly.apci.net (root@hilly.apci.net [206.100.36.3]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA26548 for <hfsig@tapr.org>; Wed, 5 Jun 1996 22:39:32 -0500 (CDT)
Received: from dialup167.apci.net (dialup167.apci.net [206.100.36.167]) by hilly.apci.net (8.6.12/8.6.9) with SMTP id WAA07740 for <hfsig@tapr.org>; Wed, 5 Jun 1996 22:40:02 -0500
Date: Wed, 5 Jun 1996 22:40:02 -0500
Message-Id: <199606060340.WAA07740@hilly.apci.net>
X-Sender: silbaugh@apci.net
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: "Eric E. Silbaugh" <silbaugh@apci.net>
Subject: Re: QPSK BANDWIDTH ?

Phil,

Good nit!  Fourier is probably turning in his grave.

I was visualizing the spectra at baseband, wrote about it as 
RF modulated, and forgot to multiply the bandwidths by two.
Arrrgggh!  Thus, the first null in a QPSK signal of T baud will
be T Hz away from the carrier; the main lobe width is 2T Hz; 
and the bandwidth with raised cosine filtering, rolloff factor 
of 0.2, will be 2.4T Hz.  

Did I get it right this time?

Eric, N2NNP

From FORRERJ@frl.orst.edu Thu Jun 06 13:20:28 1996
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA29406 for <hfsig@tapr.org>; Thu, 6 Jun 1996 13:20:23 -0500 (CDT)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU (8.6.9/8.6.9) with ESMTP id LAA10445 for <hfsig@tapr.org>; Thu, 6 Jun 1996 11:20:19 -0700
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    6 Jun 96 11:20:22 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 6 Jun 96 11:20:03 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 6 Jun 1996 11:20:01 -0800
Subject:       Further thoughts on pulse shaping for HF
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <5D1078A41EC@frl.orst.edu>

Hi folks,

Another thought/question on pulse shaping for HF; 

Consider the recovered signals from a QPSK modem where the final product 
is a raised cosine - I do encounter a little annoying sideffect. In the 
vacinity of the sampling point, one has to read both I and Q - for QPSK 
case, one expects that either I or Q must be near zero, i.e. a pair from 
the set {1,0  -1,0  0,1  0,-1  for I/Q}. 

Unfortunately, however, the pulse shaping procedure forces part of the pulse 
beyond the +/-T mark, to go negative, which, combined with a bit of jitter 
introduced by the channel effects, causes the channel that is supposed to 
be zero, to an off-zero value. These uncertainties are further aggravated 
that this error in the zero value, changes fairly rapidly in the vacinity of 
the sampling point. It would have been nice if things around the zero 
transition were a bit more stable. 

Now, if I were to use another shape function like Dolph-Chebychef, or 
the Blackman-Harris shape for minimum sidelobes, instead of raised cosines, 
I would not have true nyquist pulses - the tradeoff is a some of ISI,  
however, would'nt the result be more robust against this jitter problem as 
described above. I.e., would'nt the tradeoff between ML detection and 
robustness for clock/carrier extraction, which is more crucial, make 
sense?

Comments or suggestions would be appreciated. 

--Johan, KC7WW









From karn@qualcomm.com Thu Jun 06 20:19:35 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA14417 for <hfsig@tapr.org>; Thu, 6 Jun 1996 20:19:32 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id SAA15345; Thu, 6 Jun 1996 18:18:57 -0700 (PDT)
Date: Thu, 6 Jun 1996 18:18:57 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606070118.SAA15345@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199606060340.WAA07740@hilly.apci.net> (silbaugh@apci.net)
Subject: Re: [HFSIG:1195] Re: QPSK BANDWIDTH ?

>I was visualizing the spectra at baseband, wrote about it as 
>RF modulated, and forgot to multiply the bandwidths by two.
>Arrrgggh!  Thus, the first null in a QPSK signal of T baud will
>be T Hz away from the carrier; the main lobe width is 2T Hz; 
>and the bandwidth with raised cosine filtering, rolloff factor 
>of 0.2, will be 2.4T Hz.  

>Did I get it right this time?

Almost. The null-to-null bandwidth of 2T Hz looks right, but with
raised cosine filtering the bandwidth will be *less* than the
unfiltered null-to-null bandwidth.

Phil

From karn@qualcomm.com Thu Jun 06 20:32:11 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA14730 for <hfsig@tapr.org>; Thu, 6 Jun 1996 20:32:09 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id SAA15427; Thu, 6 Jun 1996 18:31:38 -0700 (PDT)
Date: Thu, 6 Jun 1996 18:31:38 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606070131.SAA15427@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <5D1078A41EC@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:1196] Further thoughts on pulse shaping for HF

>Consider the recovered signals from a QPSK modem where the final product 
>is a raised cosine - I do encounter a little annoying sideffect. In the 
>vacinity of the sampling point, one has to read both I and Q - for QPSK 
>case, one expects that either I or Q must be near zero, i.e. a pair from 
>the set {1,0  -1,0  0,1  0,-1  for I/Q}. 

Well, you can use any convention you like, but the usual one is to
signal with the set { (a,a), (-a,a), (-a,-a), (a,-a) } with a=sqrt(2)
times the signal magnitude and with the detectors looking
independently at the I and Q components. That is, since I and Q are
(ideally) orthogonal the I detector simply produces 1 or -1 (or a soft
decision sample somewhere in this range) without caring what is going
on in the Q channel. And vice versa.

This particular constellation is used by the 4-phase costas loop,
which will drive the I and Q components to equal amplitude. You can of
course use the constellation you described, but then you have to
rotate your decision regions so they're no longer aligned with the I
and Q axes.

Phil

From n4hy@ccr-p.ida.org Fri Jun 07 09:58:16 1996
Received: from idacrd.ccr-p.ida.org (idacrd.ccr-p.ida.org [198.3.41.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA16703 for <hfsig@tapr.org>; Fri, 7 Jun 1996 09:58:09 -0500 (CDT)
Received: from idacrd.ccr-p.ida.org (daemon@localhost) by idacrd.ccr-p.ida.org (8.7.2/8.7.2) with ESMTP id KAA03102 for <hfsig@tapr.org>; Fri, 7 Jun 1996 10:58:23 -0400 (EDT)
Received: from ccr-p.ida.org (xida.ccr-p.ida.org [198.3.6.62]) by idacrd.ccr-p.ida.org (8.7.2/8.7.2) with SMTP id KAA03098 for <hfsig@tapr.org>; Fri, 7 Jun 1996 10:58:22 -0400 (EDT)
Received: from growler.ccr-p.ida.org (growler.ccr-p.ida.org [198.3.6.3]) by ccr-p.ida.org (8.6.12/8.6.12) with ESMTP id KAA01840 for <hfsig@tapr.org>; Fri, 7 Jun 1996 10:57:41 -0400
From: Bob McGwier <n4hy@ccr-p.ida.org>
Received: (from n4hy@localhost) by growler.ccr-p.ida.org (8.7.5/8.7.3) id KAA00644 for hfsig@tapr.org; Fri, 7 Jun 1996 10:57:40 -0400 (EDT)
Date: Fri, 7 Jun 1996 10:57:40 -0400 (EDT)
Message-Id: <199606071457.KAA00644@growler.ccr-p.ida.org>
To: hfsig@tapr.org
Subject: Re: [HFSIG:1196] Further thoughts on pulse shaping for HF
In-reply-to: <5D1078A41EC@frl.orst.edu> (FORRERJ@frl.orst.edu)



A good approximation to the ML detector for clock AND data together is what
you need Johan.  Take the final pulse shape (sampled) and its derivative
(Guess at this or approximate it.  If it is raised cosine, you may compute
it).   Call these signals   P(i) and P'(i) , i = -n, -(n-1), ..., 0,1,2,...
(n-1),n respectively.  Suppose for this exercise that you have an approximate
time for the CENTER (the sampling time) for the I and Q channel bauds.

At the putative sampling time t, compute   P*S(t) and P'*S(t).  That is,
convolve the pulse shape, and its derive with the baseband signal S and do
it for S from the I and Q channel.  The SIGN of the P*S is the guessed at
symbol and  SIGN(P*S(t))*tanh [P'*S(t)] = ERROR signal to be multiplied
by the gain which will determine your "loop bandwidth".  If you are running
a first order loop for clock, this signal (gain*ERROR) is applied to the
phase of your clock and then you march along to the next symbol time.  This
is MUCH more robust, stable, etc, than using clock edges, or zero crossings,
and so long as you have the pulse shape "about right", even ISI, jitter,
does not disturb you much.  This was proposed a long time ago, before the
advent of DSP devices by Umberto Mengali.  It was proven by yours truly that
this converges under certain conditions which are near to reality to the
maximum likelihood estimator.  



A diagram of this might be more useful to nonmathematicians ;=):

               Soft Decision -> -> -> Decoder
                   |
                   |
                   |            Data
                   |              |
                   |              |
          ->->->  P*S -> -> {Hard Limiter}  ->-> |
          |                                      |
          |                                      |
S(t)  ->  |                                    Product -> -> ERROR to clock
          |
          |                                      |
          |                                      |
          ->->-> P'*S -> -> -> tanh -> -> -> ->->|

The obvious way of combining this for each channel would be to average,
or in the case of staggered, run the clock at two times the individual symbol
rate and alternate the channels feeding the clock.  You may run this as
a second order phase locked loop if you believe the clock frequency is also
unstable.  I used this to derive clock for a really noisy signal from
Venus (VEGA Balloon probe).  STAY AWAY FROM CLOCK EDGES in a really good
modem.  Implement the tanh with a table look up and/or some approximation
that you find useful.  The major condition is that the pulse shape in
a idealized channel has zero's at the baud time for neighboring bauds.
I have found it to be quite robust.  I use Passband equalization whenever
possible.  The two possible outputs for data depends on whether or not there
is error correction coding that needs soft decisions.  You will pay larger
than a 2 dB penalty to use the hard decision tap for your decoder on HF
channels should you decide to go that way.  There are other forms of this,
but this one is one of the easiest to implement.

Bob

Dr. Robert W. McGwier              | n4hy@ccr-p.ida.org: ham radio, scouts,
Center for Communications Research | astronomy, golf (o yea, & math!)
Princeton, N.J. 08520              | Cmte member Troop 5700, ACM Pack 53,
(609)-279-6240(v) (609)-924-3061(f)| Frmr Cncl Comm. GWC 362  Sanhican #2 WWW,
(609)-443-8963 (h)                 | I used to be a Buffalo . . . NE III-120
Explorer Post 995 advisor          | proud parent in Brownie Troop 196




From forrerj@ucs.orst.edu Sat Jun 08 13:18:47 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA22005 for <hfsig@tapr.org>; Sat, 8 Jun 1996 13:18:39 -0500 (CDT)
Received: from p00.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA09996; Sat, 8 Jun 1996 11:18:23 -0700
Message-Id: <1.5.4.16.19960608194055.3f8fec56@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 08 Jun 1996 11:40:55 -0800
To: hfsig@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Re: [HFSIG:1199] Re: Further thoughts on pulse shaping for HF

Hi Bob,

Thanks for sharing your ideas - also welcome to HFSIG.
 
At 10:00 AM 6/7/96 -0500, you wrote:
>
>
>A good approximation to the ML detector for clock AND data together is what
>you need Johan.  

I suspect you are right. The question that have been on my mind lately
regards how much of the ideas that we commonly use for synchronous
demodulation is worth implementing on HF. As an example, I have been playing
with a low baudrate QPSK demodulator over the last few weeks where most of
the clock and carrier extraction ideas are based on robust non-syncronous
measures. I have had some encouraging results, but everything is not quite
working either. The ideas are based roughly on the following two guidelines:

1) Do clock extraction first because 
        a) The middle of the baud is where the signal has most energy and
there is
           best phase stability (stay away from the transition zones).
        b) Attempt carrier extraction *only* during this stable period.

2) Decision-directed carrier extraction - preferably not based on PLL's or
Costas loops.
 
On the latter subject; I have played and struggled with various ideas - what
I found was that the extended Costas loop (i.e., with I/Q sgn and summming
of cross products) works very nicely indeed with waveforms that is not
overly distorted. In fact in Frerking's book (Digital Signal Processing in
Communications Systems, Marvin Frerking ISBN 0442016166 p.444) makes you
aware of the fact that you *not* use the output of a matched filter but a
lowpass filter to steer the Costas loop. I have found this to be valid.

This is one reason why I'm quite interested in certain constellations that
is easier to deal with than others.     


>Take the final pulse shape (sampled) and its derivative
>(Guess at this or approximate it.  If it is raised cosine, you may compute
>it).   Call these signals   P(i) and P'(i) , i = -n, -(n-1), ..., 0,1,2,...
>(n-1),n respectively.  Suppose for this exercise that you have an approximate
>time for the CENTER (the sampling time) for the I and Q channel bauds.
>
>At the putative sampling time t, compute   P*S(t) and P'*S(t).  That is,
>convolve the pulse shape, and its derive with the baseband signal S and do
>it for S from the I and Q channel.  The SIGN of the P*S is the guessed at
>symbol and  SIGN(P*S(t))*tanh [P'*S(t)] = ERROR signal to be multiplied
>by the gain which will determine your "loop bandwidth".  If you are running
>a first order loop for clock, this signal (gain*ERROR) is applied to the
>phase of your clock and then you march along to the next symbol time.  This
>is MUCH more robust, stable, etc, than using clock edges, or zero crossings,
>and so long as you have the pulse shape "about right", even ISI, jitter,
>does not disturb you much.  This was proposed a long time ago, before the
>advent of DSP devices by Umberto Mengali.  It was proven by yours truly that
>this converges under certain conditions which are near to reality to the
>maximum likelihood estimator.  

Ah .. I like this idea and will give it some more thought. Could you be so
kind and give us the full references.


>
>
>
>A diagram of this might be more useful to nonmathematicians ;=):
>
>               Soft Decision -> -> -> Decoder
>                   |
>                   |
>                   |            Data
>                   |              |
>                   |              |
>          ->->->  P*S -> -> {Hard Limiter}  ->-> |
>          |                                      |
>          |                                      |
>S(t)  ->  |                                    Product -> -> ERROR to clock
>          |
>          |                                      |
>          |                                      |
>          ->->-> P'*S -> -> -> tanh -> -> -> ->->|
>
>The obvious way of combining this for each channel would be to average,
>or in the case of staggered, run the clock at two times the individual symbol
>rate and alternate the channels feeding the clock.  You may run this as
>a second order phase locked loop if you believe the clock frequency is also
>unstable.  I used this to derive clock for a really noisy signal from
>Venus (VEGA Balloon probe).  STAY AWAY FROM CLOCK EDGES in a really good
>modem.  

I guess we agree that the usual synchronous demodulation ideas needs careful
rethinking.

>Implement the tanh with a table look up and/or some approximation
>that you find useful.  The major condition is that the pulse shape in
>a idealized channel has zero's at the baud time for neighboring bauds.

Would it thus be an advantage to use such a shaping function; I do know that
the Dolph-chebycheff and Blackman-Harris shapes, for example, was designed
for that.

>I have found it to be quite robust.  I use Passband equalization whenever
>possible.  

How is this done? using adaptive FIR structures? does this require some kind
of training sequence?

>The two possible outputs for data depends on whether or not there
>is error correction coding that needs soft decisions.  You will pay larger
>than a 2 dB penalty to use the hard decision tap for your decoder on HF
>channels should you decide to go that way.  There are other forms of this,
>but this one is one of the easiest to implement.
>
>Bob
>
>Dr. Robert W. McGwier              | n4hy@ccr-p.ida.org: ham radio, scouts,
>Center for Communications Research | astronomy, golf (o yea, & math!)
>Princeton, N.J. 08520              | Cmte member Troop 5700, ACM Pack 53,
>(609)-279-6240(v) (609)-924-3061(f)| Frmr Cncl Comm. GWC 362  Sanhican #2 WWW,
>(609)-443-8963 (h)                 | I used to be a Buffalo . . . NE III-120
>Explorer Post 995 advisor          | proud parent in Brownie Troop 196
>
>
>
>
>

Pardon if I seem too inquisitive and ask too many dumb questions.


--Johan, KC7WW 

From hardie@duke.usask.ca Sat Jun 08 14:47:08 1996
Received: from duke.usask.ca (duke.usask.ca [128.233.3.13]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA24958 for <hfsig@tapr.org>; Sat, 8 Jun 1996 14:47:05 -0500 (CDT)
Received: from localhost (hardie@localhost) by duke.usask.ca (8.7.3/8.7.3) with SMTP id NAA09131 for <hfsig@tapr.org>; Sat, 8 Jun 1996 13:46:57 -0600 (CST)
Date: Sat, 8 Jun 1996 13:46:57 -0600 (CST)
From: Pete Hardie <hardie@duke.usask.ca>
To: hfsig@tapr.org
Subject: Stuck at the beginning

In-Reply-To: <1.5.4.16.19960608194055.3f8fec56@ucs.orst.edu>
Message-ID: <Pine.OSF.3.93.960608132158.5705A-100000@duke.usask.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'm just starting with DSP and thought (after creating some CW FIR
filters) that I'd try to implement a 1200 baud packet TNC on the EZ-KIT
Lite.
I had assumed that implementing the modulation side of this was going to
be easy but I've run into a major hurdle that I can't figure out.

Generating the NRZI data and modulating it as a continuous phase FSK audio
signal was easy. I have set up the DSP program so that it reads KISS
packets from the RS-232 port and then generates the FSK. However, if I put
the audio from the Kit into either my KAM or Tiny-2 neither of them will
decode a packet. I tried this with passall on so that even if the CRC were
bad they should print something out - but they don't. In both cases their
DCD LED does come on while the packet audio is present so they're seeing
something. (BTW - I have used a frequency counter to check the frequency
and stability of the generated tones and of the data bit rate and they're
bang on). 

Next step was that I wrote two programs on my Amiga. One samples the
parallel port (I called this program "scope") and the other (called
"nrzi") takes the results from "scope" and decodes it back to the original
data bits (and if the CRC is OK it also attempts to print the AX25
header). 
 
I connect the NRZI digital output of the TNC's modem (3105) into the
parallel port and "scope" samples this at any rate I choose. 

If I play the DSP audio into the TNC and sample its modem's NRZI output,
"nrzi"  decodes it with no problem. But, if I look at the RS-232 output of
the TNC itself it doesn't send the content of the packet to the computer. 

The bit that really throws me is that if I connect the TNC to the audio
from my radio and then run "scope" and "nrzi" on what the TNC hears, the
"nrzi"  program decodes "real" packets without any trouble too and this is
using exactly the same sampling rates as I used to sample the audio from
the DSP.

The fact that I can decode the NRZI output from the TNC modem eliminates
several possible problems such as incorrect audio tones and the fact that
the "nrzi" program can decode "real" packets using the modem's NRZI output 
suggests that the timing is also correct. 

I'm lost. I know this is "back to basics" for most of you but has anyone
any idea where I can start looking for the problem?

73 de Pete  
ve5va.qrp@usask.ca

From mwestfal@csci.csusb.edu  Sat Jun 08 21:19:21 1996
Received: from silicon.csci.csusb.edu (silicon.csci.csusb.edu [139.182.38.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id VAA09069 for <hfsig@tapr.org>; Sat, 8 Jun 1996 21:19:18 -0500 (CDT)
Received: by silicon.csci.csusb.edu (5.0/SMI-SVR4)
	id AA12396; Sat, 8 Jun 1996 19:33:41 +0800
From: mwestfal@csci.csusb.edu (Michael Westfall)
Received: by csci.csusb.edu id TAA20047; Sat, 8 Jun 1996 19:22:49 -0700 (PDT) (8.7.1 Berkeley Sendmail)
Message-Id: <199606090222.TAA20047@csci.csusb.edu>
Subject: Re: [HFSIG:1201] Stuck at the beginning
To: hfsig@tapr.org
Date: Sat, 8 Jun 1996 19:22:48 -0700 (PDT)
In-Reply-To: <Pine.OSF.3.93.960608132158.5705A-100000@duke.usask.ca> from "Pete Hardie" at Jun 8, 96 02:57:28 pm
Reply-To: mwestfal@csci.csusb.edu
X-Hi-Mom: Send more money!
Organization: The Hackers' Guild
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text

> I'm just starting with DSP and thought (after creating some CW FIR
> filters) that I'd try to implement a 1200 baud packet TNC on the EZ-KIT
> Lite.
> I had assumed that implementing the modulation side of this was going to
> be easy but I've run into a major hurdle that I can't figure out.
> 
> Generating the NRZI data and modulating it as a continuous phase FSK audio
> signal was easy. I have set up the DSP program so that it reads KISS
> packets from the RS-232 port and then generates the FSK. However, if I put
> the audio from the Kit into either my KAM or Tiny-2 neither of them will
> decode a packet. 

I would guess what you are forgetting is to add the HDLC frame flags and 
bit-stuffing....

> 
> I'm lost. I know this is "back to basics" for most of you but has anyone
> any idea where I can start looking for the problem?

I'm no expert, so I'll defer to someone else to explain further...
-------------------------------------------------------------------------------
73 de Mike,      ax.25net:    N6KUY@W6JBT.#SOCA.CA.USA.NA 
                  amprnet:    n6kuy@n6kuy.ampr.org [44.18.0.49] 
                internet :    mwestfal@csci.csusb.edu
                     web:     http://orion.csci.csusb.edu:8080
               "Linux: The Gates of Hell shall not prevail."
GCS/M { -d+ p+ c++ l u++ e+(*) m++(-) s/+ !n-(---) h-- !f g+ w+ t++ r-(--) y+ }
-------------------------------------------------------------------------------

From hardie@duke.usask.ca Sat Jun 08 22:27:03 1996
Received: from duke.usask.ca (duke.usask.ca [128.233.3.13]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA11050 for <hfsig@tapr.org>; Sat, 8 Jun 1996 22:27:00 -0500 (CDT)
Received: from localhost (hardie@localhost) by duke.usask.ca (8.7.3/8.7.3) with SMTP id VAA08814 for <hfsig@tapr.org>; Sat, 8 Jun 1996 21:26:57 -0600 (CST)
Date: Sat, 8 Jun 1996 21:26:57 -0600 (CST)
From: Pete Hardie <hardie@duke.usask.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:1202] Re: Stuck at the beginning
In-Reply-To: <199606090222.TAA20047@csci.csusb.edu>
Message-ID: <Pine.OSF.3.93.960608212140.22169A-100000@duke.usask.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 8 Jun 1996, Michael Westfall wrote:

> I would guess what you are forgetting is to add the HDLC frame flags and 
> bit-stuffing....

That's all in there Mike because:
(a) I know they are in the DSP program.
(b) My "nrzi" program which decodes the signals not only decodes mine
correctly from the DSP but it also correctly decodes real packets off the
air. So my DSP has to be generating the flags and bit-stuffing otherwise 
the "nrzi" program wouldn't decode it. 

Thanks for the reply.

73 de Pete
ve5va.qrp@usask.ca

From forrerj@ucs.orst.edu Sun Jun 09 01:00:05 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA23096 for <hfsig@tapr.org>; Sun, 9 Jun 1996 01:00:03 -0500 (CDT)
Received: from p04.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA05625; Sat, 8 Jun 1996 22:59:57 -0700
Message-Id: <1.5.4.16.19960609072233.38677264@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 08 Jun 1996 23:22:33 -0800
To: hfsig@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Re: [HFSIG:1201] Stuck at the beginning

Hi Pete,

My two cent's worth:




>
>The fact that I can decode the NRZI output from the TNC modem eliminates
>several possible problems such as incorrect audio tones and the fact that
>the "nrzi" program can decode "real" packets using the modem's NRZI output 
>suggests that the timing is also correct. 
>

Seems like "nrzi" can decode both packets taken from your TNC's modem and
your DSP signal source - so that looks like the format is OK. 

Have you looked at the audio levels going to the real TNC when you try your
DSP signal source? Perhaps they are overdriving the TNC. TNC's are quite
sensitive to the level and the fact that you see DCD comes on may not mean
too much. Perhaps some form of level adjustment may help. Otherwise, I would
defininately listen to that audio with an amplified speaker or scope and
determine whether is clean and without hum.


>I'm lost. I know this is "back to basics" for most of you but has anyone
>any idea where I can start looking for the problem?
>
>73 de Pete  
>ve5va.qrp@usask.ca
>
>

Looks like you are well on your way.

--Johan

From hardie@duke.usask.ca Sun Jun 09 20:29:18 1996
Received: from duke.usask.ca (duke.usask.ca [128.233.3.13]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA00317 for <hfsig@tapr.org>; Sun, 9 Jun 1996 20:25:26 -0500 (CDT)
Received: from localhost (hardie@localhost) by duke.usask.ca (8.7.3/8.7.3) with SMTP id TAA30004 for <hfsig@tapr.org>; Sun, 9 Jun 1996 19:23:56 -0600 (CST)
Date: Sun, 9 Jun 1996 19:23:56 -0600 (CST)
From: Pete Hardie <hardie@duke.usask.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:1204] Re: Stuck at the beginning
In-Reply-To: <1.5.4.16.19960609072233.38677264@ucs.orst.edu>
Message-ID: <Pine.OSF.3.93.960609191716.28968A-100000@duke.usask.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 9 Jun 1996, Johan Forrer wrote:

> Seems like "nrzi" can decode both packets taken from your TNC's modem and
> your DSP signal source - so that looks like the format is OK. 
> 
> Have you looked at the audio levels going to the real TNC when you try your
> DSP signal source? Perhaps they are overdriving the TNC.

I have checked that out and it doesn't make any difference. I wasn't sure
that it should because the signal that "nrzi" sees is what the modem has
decoded from the audio input. If the audio were overdriving the modem then
I would expect the program to see that as errors in the nrzi bitstream
coming out of the modem but "nrzi" has no trouble decoding the bitstream.

> Otherwise, I would
> defininately listen to that audio with an amplified speaker or scope and
> determine whether is clean and without hum.

I have listened to the audio and it sounds exactly like the packets I hear
on the air. I haven't got a scope but I'm going to try to borrow one to
have a look at the nrzi bitstream from the TNC's modem. Perhaps there are
subtle timing differences which don't show up due to the nature of my
sampling program. 

Thanks Johan.

Pete

From karn@qualcomm.com Mon Jun 10 19:40:27 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA27043 for <hfsig@tapr.org>; Mon, 10 Jun 1996 19:40:17 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id RAA29160; Mon, 10 Jun 1996 17:39:42 -0700 (PDT)
Date: Mon, 10 Jun 1996 17:39:42 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606110039.RAA29160@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <1.5.4.16.19960608194055.3f8fec56@ucs.orst.edu> (message from Johan Forrer on Sat, 8 Jun 1996 13:35:25 -0500 (CDT))
Subject: Re: [HFSIG:1200] Re: Further thoughts on pulse shaping for HF

While the usual methods for extracting timing were designed for
continuous streams of bits, I point out that just about all of our
applications now involve packetized data of one sort or another. So
that opens up some alternative methods for timing extraction, like a
one-shot scheme based on a sync vector in the front of the packet.

That is, instead of continuously recovering clock from the data
stream, you estimate it once during each packet and extrapolate it
from there. This is easy to do by sliding a correlator over the packet
-- when it hits its peak, you just count off the proper number of
samples per bit for the rest of the packet. Much easier.

With even cheap crystals being as good as they usually are, one-shot
timing schemes work pretty well as long as the packet size is limited
-- which it is anyway for many other reasons.

Too bad that one-shot schemes won't work for carrier recovery -- there's
too much doppler, noise and/or other impairments for this to work, so
you have to extract it as before with a Costas loop or something similar.

Phil

From forrerj@ucs.orst.edu Wed Jun 12 11:01:08 1996
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA29111 for <HFSIG@TAPR.ORG>; Wed, 12 Jun 1996 11:01:01 -0500 (CDT)
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA05079; Wed, 12 Jun 1996 09:00:45 -0700
Date: Wed, 12 Jun 1996 09:00:45 -0700 (PDT)
From: Johan Forrer <forrerj@ucs.orst.edu>
To: HFSIG@tapr.org
Subject: Re: [HFSIG:1206] Re: Further thoughts on pulse shaping for HF
In-Reply-To: <65E6D933EE1@frl.orst.edu>
Message-Id: <Pine.OSF.3.91.960612084342.19054A-100000@ucs.orst.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Phil,


> 
> 
> While the usual methods for extracting timing were designed for
> continuous streams of bits, I point out that just about all of our
> applications now involve packetized data of one sort or another. So
> that opens up some alternative methods for timing extraction, like a
> one-shot scheme based on a sync vector in the front of the packet.

It is true that nearly all communications nowadays have some form of 
header that allows for this kind of one-shot sync. Could you tell us a 
bit more about the sync vector that you are now using. I did follow some 
discussion a while ago about your explorations for a suitable sync vector.

I now have reasonable clock and data extraction working, but I am working 
on extending the code to look for a sync vector. Although transmission of 
the main data stream is DQPSK, I use ordinary DPSK for the sync vector. 
I'll do as you suggest - obtain and set the clock at that point it 
recognises the sync vector. My observations have been that there is a 
fraction of a bit's worth slippage across my packets - not too much to be 
of concern.

I also am considering using offset QPSK and was wondering; would the 
extended Costas loop as for QPSK work for offset QPSK, or would I 
need to change it?

> 
> 
>That is, instead of continuously recovering clock from the data 
> stream, you estimate it once during each packet and extrapolate it
> from there. This is easy to do by sliding a correlator over the packet
> -- when it hits its peak, you just count off the proper number of
> samples per bit for the rest of the packet. Much easier.
> 
> With even cheap crystals being as good as they usually are, one-shot
> timing schemes work pretty well as long as the packet size is limited
> -- which it is anyway for many other reasons.
> 
> Too bad that one-shot schemes won't work for carrier recovery -- there's
> too much doppler, noise and/or other impairments for this to work, so
> you have to extract it as before with a Costas loop or something similar.
> 
> Phil
> 
>

The idea here is to use a number of orthogonal channels for data, one 
channel will be unmodulated just to extract doppler.

The project has been a lot of fun but sure burns time and effort. 
However, I'm learning a lot too.

--Johan

From karn@qualcomm.com Wed Jun 12 23:21:21 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA27501 for <hfsig@tapr.org>; Wed, 12 Jun 1996 23:21:19 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id VAA01103; Wed, 12 Jun 1996 21:20:42 -0700 (PDT)
Date: Wed, 12 Jun 1996 21:20:42 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606130420.VAA01103@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <Pine.OSF.3.91.960612084342.19054A-100000@ucs.orst.edu> (message from Johan Forrer on Wed, 12 Jun 1996 11:09:06 -0500 (CDT))
Subject: Re: [HFSIG:1207] Re: Further thoughts on pulse shaping for HF

>header that allows for this kind of one-shot sync. Could you tell us a 
>bit more about the sync vector that you are now using. I did follow some 

Well, I haven't settled on a final vector yet, but at the moment I'm
using a 26-bit vector constructed from the 13-bit Barker code (the
longest-known binary Barker code) with each bit Manchester encoded.
I.e., a "1" becomes "10" and a "0" becomes "01".

This does several things. It adds energy to the total vector, making
it easier to spot reliably, and it also adds two negative sidelobes
right next to the main positive lobe. In radar where you don't have
polarity information and are forced to look at signal envelopes, this
would be a big drawback. But this is actually an advantage to me since

I already have signal polarity from the carrier preamble, and the negative
sidelobes "sharpen" the main lobe, making it less likely for me to lock
one (or more) samples off the center of the main lobe.

I've simulated this vector pretty heavily and it seems adequate at the
nominal modem Eb/N0 of 3dB, but I wouldn't mind a little more margin.

Phil




From karn@qualcomm.com Wed Jun 12 23:30:57 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA27681 for <hfsig@tapr.org>; Wed, 12 Jun 1996 23:30:53 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id VAA01120; Wed, 12 Jun 1996 21:30:22 -0700 (PDT)
Date: Wed, 12 Jun 1996 21:30:22 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606130430.VAA01120@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <Pine.OSF.3.91.960612084342.19054A-100000@ucs.orst.edu> (message from Johan Forrer on Wed, 12 Jun 1996 11:09:06 -0500 (CDT))
Subject: Re: [HFSIG:1207] Re: Further thoughts on pulse shaping for HF

>I also am considering using offset QPSK and was wondering; would the 
>extended Costas loop as for QPSK work for offset QPSK, or would I 
>need to change it?

Yes, it works. The scheme I've been using is to sample both I&Q twice
per symbol, once at the center of the I symbol and again at the center
of the Q symbol. Two of these samples obviously become the recovered
data symbols. The out-of-phase samples (e.g., the one of the Q-channel
taken at the I-channel sampling instant) has its sign flipped by the
polarity of the current in-phase sample. Then the polarity corrected
out-of-phase Q-channel samples are subtracted from the polarity
corrected out-of-phase I-channel samples, producing the phase
residuals that my loop attempts to minimize in a least-squares
fashion.

This is basically the classic decision-directed 4-phase costas loop,
implemented in a sampled system.

I've been looking more closely at your exact question over the past
day or two. With my current scheme it *seems* that with SQPSK (but not
plain QPSK) there exist data patterns that produce no phase detector
output even when there is a carrier phase error. If you number the
four phase states 1-2-3-4, imagine an encoded phase sequence that goes
1-2-3-4-1-2-3-4 (or 4-3-2-1-4-3-2-1). (This corresponds roughly to an
unmodulated carrier offset above or below the real carrier). In this
case, all of the out-of-phase symbols are in the process of changing
when they're sampled by the in-phase symbol, leaving no residual even
when there's a carrier phase error.

The scheme still seems to work, at least for the random-like data
produced by the convolutional coder and interleaver, but this
phenomenon still bothers me. If nothing else, it means that the gain
of the "loop" (and the speed at which it converges) depends on the
signal pattern as well as the amplitude of the signal. Although this
doesn't actually affect the error performance of the modem (since I
operate in an a-posteriori batch mode where I repeatedly crunch each
block of symbols until I find the steady-state maximum likelihood
carrier phase and frequency), it does affect the cost in CPU cycles.

More when I figure this all out for myself.

Phil

From karn@qualcomm.com Wed Jun 12 23:34:53 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA27983 for <hfsig@tapr.org>; Wed, 12 Jun 1996 23:34:50 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id VAA01148; Wed, 12 Jun 1996 21:34:19 -0700 (PDT)
Date: Wed, 12 Jun 1996 21:34:19 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606130434.VAA01148@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <Pine.OSF.3.91.960612084342.19054A-100000@ucs.orst.edu> (message from Johan Forrer on Wed, 12 Jun 1996 11:09:06 -0500 (CDT))
Subject: Re: [HFSIG:1207] Re: Further thoughts on pulse shaping for HF

>The idea here is to use a number of orthogonal channels for data, one 
>channel will be unmodulated just to extract doppler.

How well does the carrier reference channel work in practice, given
multipath?  Can you really just lock a loop to it and derive carrier
phase for all your other channels, eliminating all the squaring (or
worse) losses inherent in suppressed carrier systems?

Phil

From forrerj@ucs.orst.edu Thu Jun 13 11:38:37 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA27391 for <hfsig@tapr.org>; Thu, 13 Jun 1996 11:38:34 -0500 (CDT)
Received: from p00.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA14059; Thu, 13 Jun 1996 09:38:27 -0700
Message-Id: <1.5.4.16.19960613180144.3ff78574@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Jun 1996 10:01:44 -0800
To: hfsig@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Re: [HFSIG:1210] Re: Further thoughts on pulse shaping for HF

Phil,

At 11:49 PM 6/12/96 -0500, you wrote:
>>The idea here is to use a number of orthogonal channels for data, one 
>>channel will be unmodulated just to extract doppler.
>
>How well does the carrier reference channel work in practice, given
>multipath?  Can you really just lock a loop to it and derive carrier
>phase for all your other channels, eliminating all the squaring (or
>worse) losses inherent in suppressed carrier systems?
>
>Phil
>
>

That's a good question. Perhaps someone like Hakan, who are more familiar
with MIL-STD 188 or STANAG modems could tell us more about that. I have seen
the idea used for doppler compensation in both the 39 and 16 tone modems for
this purpose. Perhaps to deal with a kind of doppler that affects the block
of frequencies as a whole instead of only selective channels. As to how
valid or effective that is, I really don't know.

Someone care to comment?

--Johan

From forrerj@ucs.orst.edu Thu Jun 13 11:38:40 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA27392 for <hfsig@tapr.org>; Thu, 13 Jun 1996 11:38:37 -0500 (CDT)
Received: from p00.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA04085; Thu, 13 Jun 1996 09:38:22 -0700
Message-Id: <1.5.4.16.19960613180138.3ff7efd0@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Jun 1996 10:01:38 -0800
To: hfsig@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Re: [HFSIG:1209] Re: Further thoughts on pulse shaping for HF

Hi Phil,

At 11:49 PM 6/12/96 -0500, you wrote:
>>I also am considering using offset QPSK and was wondering; would the 
>>extended Costas loop as for QPSK work for offset QPSK, or would I 
>>need to change it?
>
>Yes, it works. The scheme I've been using is to sample both I&Q twice
>per symbol, once at the center of the I symbol and again at the center
>of the Q symbol. Two of these samples obviously become the recovered
>data symbols. The out-of-phase samples (e.g., the one of the Q-channel
>taken at the I-channel sampling instant) has its sign flipped by the
>polarity of the current in-phase sample. Then the polarity corrected
>out-of-phase Q-channel samples are subtracted from the polarity
>corrected out-of-phase I-channel samples, producing the phase
>residuals that my loop attempts to minimize in a least-squares
>fashion.

Thanks - good to know that.

>
>This is basically the classic decision-directed 4-phase costas loop,
>implemented in a sampled system.
>
>I've been looking more closely at your exact question over the past
>day or two. With my current scheme it *seems* that with SQPSK (but not
>plain QPSK) there exist data patterns that produce no phase detector
>output even when there is a carrier phase error. If you number the
>four phase states 1-2-3-4, imagine an encoded phase sequence that goes
>1-2-3-4-1-2-3-4 (or 4-3-2-1-4-3-2-1). (This corresponds roughly to an
>unmodulated carrier offset above or below the real carrier). In this
>case, all of the out-of-phase symbols are in the process of changing
>when they're sampled by the in-phase symbol, leaving no residual even
>when there's a carrier phase error.

I follow - interesting that SQPSK has that anomaly. I was going to ask
whether you are using a scrambler as that would reduce the recurrence of
such a pattern, but your convolutional coding and interleaver will probably
have the same effect to randomize the pattern.


>
>The scheme still seems to work, at least for the random-like data
>produced by the convolutional coder and interleaver, but this
>phenomenon still bothers me. If nothing else, it means that the gain
>of the "loop" (and the speed at which it converges) depends on the
>signal pattern as well as the amplitude of the signal. Although this
>doesn't actually affect the error performance of the modem (since I
>operate in an a-posteriori batch mode where I repeatedly crunch each
>block of symbols until I find the steady-state maximum likelihood
>carrier phase and frequency), it does affect the cost in CPU cycles.

I played with a decision-directed scheme for a while that, at the middle of
the symbol, found the closest constellation point, and then determines
whether the received constellation needed to be rotated clockwise or
anti-clockwise. When the set of constellation points were {(1 0), (0 -1),
(-1 0), (0 -1)}, then either I or Q needed to be zero. One could then use
this non-zero offset as an (magnitude, direction) error estimate to be used
for loop control. This worked wonderfully until I started using RC pulse
shaping - the zero-crossing transitions for the RC pulses just played havoc.
At that point I switched to the extended Costas loop that took care of it,
however, as you said in an earlier posting, that type of loop drives I and Q
maximal and in my case, the transmitted and received constallations are
offset by a constant 45 degrees. That does not bother differential coding as
long as it is a stable lock, which is the case. I find that I can start the
demodulator midst of a random data sequence, obtain and hold lock - even for
33 second packets. 

>
>More when I figure this all out for myself.
>
>Phil
>
>

Let us know the outcome - I'm curious.

--Johan

From zs6awk@global.co.za  Fri Jun 14 16:51:36 1996
Received: from lin01.global.co.za (lin01.global.co.za [196.3.164.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA03934 for <hfsig@tapr.org>; Fri, 14 Jun 1996 16:50:03 -0500 (CDT)
Received: from mail.global.co.za ([196.3.168.58]) by lin01.global.co.za (8.7.3/8.7.3) with SMTP id XAA27977 for <hfsig@tapr.org>; Fri, 14 Jun 1996 23:48:12 -0200 (GMT)
Message-Id: <199606150148.XAA27977@lin01.global.co.za>
X-Sender: zs6awk@mail.global.co.za (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 14 Jun 1996 23:49:42 +0200
To: hfsig@tapr.org
From: zs6awk@global.co.za (Danie Brynard)
Subject: re pos of filter vs nyquist

I have been playing around with simulations to see if the position of a FIR
filter is important relative to the Nyquist frequency. Thus if I have a BPF
of say arbitrary passband and stopband does it matter where I place this
filter in the frequency range 0Hz to Fnyquist Hz ? (Fnyq=Fs/2)

According to my simulations it does not matter but I am not convinced. In
the analog world the rule is: the higher the freqency the more difficult it
is to make the same BPF.

Is wordlength or calculation precision perhaps the answer ? Is the number of
cycles per unit time of the wanted signal perhaps the answer ?

Could somebody give me a 'gut-feel' answer ? In other words a layman
explanation why it does/does not matter where one puts the filter.

I hope I explained myself well enough. Looking forward to all the
interesting replies :-)

73 danie zs6awk@global.co.za

From hakan.bergzen@enator.se Sat Jun 15 10:40:42 1996
Received: from gk.enator.se (ns.enator.se [147.13.200.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA18040 for <hfsig@tapr.org>; Sat, 15 Jun 1996 10:40:31 -0500 (CDT)
Received: from janus.vxo.telub.se ([147.13.8.25]) by gk.gk.enator.se with SMTP id <35746>; Sat, 15 Jun 1996 17:40:37 +0100
Received: from noak.vxo.enator.se by janus.vxo.telub.se with SMTP (PP) 
          id <11592-0@janus.vxo.telub.se>; Sat, 15 Jun 1996 17:35:10 +0200
Received: by noak with Microsoft Mail id <31CDE3D2@noak>;
          Sat, 15 Jun 96 17:39:46 +02
From: "Bergzen Hakan, KARL" <hakan.bergzen@enator.se>
To: hfsig <hfsig@tapr.org>
Subject: Re: Further thoughts on pulse shaping for HF
Date: Sat, 15 Jun 1996 16:39:00 +0100
Message-ID: <31CDE3D2@noak>
Return-Receipt-To: HABE <hakan.bergzen@enator.se>
Encoding: 67 TEXT
X-Mailer: Microsoft Mail V3.0
MIME-Version: 1.0
Content-Type: Text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit


Johan,

I have not been able to monitor this group for some time, just trying to 
catch up, when I saw your reference to me. Even though I doubt I would have 
some information which not you and Phil already knows (I am very impressed 
of both of you being able to give the rest of us elaborate responses to our 
various questions, comments and ideas). This probably also goes for several 
silent readers of this group.

>>>The idea here is to use a number of orthogonal channels for data, one
>>>channel will be unmodulated just to extract doppler.
>>
>>How well does the carrier reference channel work in practice, given
>>multipath?  Can you really just lock a loop to it and derive carrier
>>phase for all your other channels, eliminating all the squaring (or
>>worse) losses inherent in suppressed carrier systems?
>>
>That's a good question. Perhaps someone like Hakan, who are more familiar
>with MIL-STD 188 or STANAG modems could tell us more about that. I have 
seen
>the idea used for doppler compensation in both the 39 and 16 tone modems 
for
>this purpose. Perhaps to deal with a kind of doppler that affects the block
>of frequencies as a whole instead of only selective channels. As to how
>valid or effective that is, I really don't know.

The parallel tone modes within MIL-STD-188-110A use a special doppler 
correction tone, which will run continuously. It is the lowest tone in both 
modes (605 Hz for the 16-tone mode and 393.75 Hz for the 39-tone mode). It 
is only used for doppler correction, thus enabling the DSP to adjust the 
frequency offset for all data tones up or down correspondingly before symbol 
demodulation.

Both modes use BDPSK and QDPSK (depending on the data rate selected). At the 
lower data rates DPSK and in-band diversity combining are used. The 39-tone 
mode also use interleavers. Since only differential encoding is used the 
symbol decoding problem is more or less eliminated (I dont think it is 
possible to extract a carrier phase for one tone and use it for any other 
tone).

The protocol uses an initial preamble. The 39-tone mode use a 3-part 
preamble of different data tones all-in-all 23 signal elements (An extended 
preamble uses 97 signal elements). The data to be sent is divided into 
blocks. Each data block starts with a block sync. The block length depends 
on interleaver depth and data rate selected. A transmission is ended with an 
End-of-message sequence.

I think it would be a good idea to include a superb feature defined in the 
serial tone mode of the MIL-STD-188-110A, namely the Autobaud function. 
Within the initial preamble (and the re-occuring preamble enabling re-sync) 
the data rate and interleaver setting is encoded. This enables a receiving 
modem to automatically make the correct parameter setting and receive the 
message. The transmitting modem can by itself decide upon the most suitable 
data rate/interleaver depth.This makes it e.g. possible to easily construct 
adaptive ARQ schemes.

The trend in Europe and the U.S. seems to go from parallel tone modems to 
serial tone modems. They are more tricky to construct (including adaptive 
channel equalizers) but they show better performance because of their better 
utilization of the available channel (a sort of narrow-band SS, really). 
Though recent Australian studies (DSTO) using parallel tone modems together 
with trellis coding claims to perform better than serial tone modems.

For what it's worth...

Hakan    (hakan.bergzen@enator.se)

From JSANFORD@INFI.NET Sat Jun 15 20:05:03 1996
Received: from mh004.infi.net (mailhost.infi.net [205.219.238.95]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA07794 for <hfsig@tapr.org>; Sat, 15 Jun 1996 20:04:48 -0500 (CDT)
Received: from pa9dsp3.orf.infi.net by mh004.infi.net with SMTP 
	(Infinet-S-3.3) id VAA28286; Sat, 15 Jun 1996 21:04:17 -0400 (EDT)
Message-Id: <199606160104.VAA28286@mh004.infi.net>
X-Sender: jsanford@infi.net
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 15 Jun 1996 21:04:37 -0400
To: hfsig@tapr.org
From: Jim Sanford <JSANFORD@INFI.NET>
Subject: Re: [HFSIG:1190] Re: QPSK BANDWIDTH ?

Phil
Forgive the long delay  . .. the cost of my job which takes me
to sea . . .

Your comment about filters is part of why I'm hoping to do the thing
with simple chips and do ALL filtering in DSP.  Of course, Ulrich Rhode
will remind me that a "ROOFING" filter would improve s/n in the IF . . .

Goal is acceptable performance at low cost and ease of duplication.  I'm 
hoping to turn this project into a kit for our club . . .

At 03:22 PM 6/4/96 -0500, you wrote:
>>        1.  For what platform are you doing the OQPSK
>>satellite modem?  I have 2 dsp-12's and would love to
>>beta test . . .
>
>The platform is a generic 486 or Pentium PC running my KA9Q NOS TCP/IP
>package. The modem will be integrated in as an interface driver for a
>SoundBlaster 16 card *without* any special DSP chips.
>
>Your work with the 'digital friendly' receiver sounds very
>interesting!  I do hope that whatever you come up with can be easily
>replicated by the average amateur -- in my experience, that's where
>many promising amateur hardware projects fall down. It's the main
I absolutely agree...

>reason I've become so interested in using mass-market PC hardware to
>the greatest possible extent, doing everything else in software. But
>there are definite limits to the available hardware (particularly in
>the radios) so your work is most welcome. I agree, this stuff ought
>not to be as expensive and complicated as it seems to be.
I've been somewhat against using stuff in a PC because I hate the thought 
of tying up a PC for a single function, but you've got a GREAT point 
about the cost of mass market hardware vs anything for the much smaller
ham market.  And, as costs of PC's drop . . . .

I'm already dedicating a 486/overdrive to the pacsats, so, what's another
cheap 486 on the network . . .  <grin>

Thanks again for all you've done....73, Jim
wb4gcs

>The guy behind the Fox-Tango table, being used to selling very sharp
>and narrow crystal filters for HF contest and DX use, couldn't figure
>out why in the world I would want to make my rig go *wider*. Ah, the
>"narrowband mindset" seems pretty well entrenched. :-)
>

From zs6awk@global.co.za  Sun Jun 16 14:55:40 1996
Received: from lin01.global.co.za (lin01.global.co.za [196.3.164.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA25148 for <hfsig@tapr.org>; Sun, 16 Jun 1996 14:55:30 -0500 (CDT)
Received: from anx_80.global.co.za (anx_80.global.co.za [196.3.164.130]) by lin01.global.co.za (8.7.3/8.7.3) with SMTP id VAA03929 for <hfsig@tapr.org>; Sun, 16 Jun 1996 21:53:37 -0200 (GMT)
Message-Id: <199606162353.VAA03929@lin01.global.co.za>
X-Sender: zs6awk@mail.global.co.za (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 16 Jun 1996 21:55:02 +0200
To: hfsig@tapr.org
From: zs6awk@global.co.za (Danie Brynard)
Subject: Re: [HFSIG:868] Re: DSP Tools

Phil is there perhaps a book that you can suggest if one wants to read more
about the inner working of the 486 and Pentuim and also on real-time
programming of it in assembler ? Something perhaps like 'asm programming on
the Pentuim for beginners' :-)

I am hooked onto the Motorola DSP56xxx family but is interested in your ideas..

danie zs6awk
zs6awk@global.co.za

>At 06:22 PM 2/8/96 -0600, you wrote:
>
>>As for DSP development platforms.  Both TI (www.ti.com) and Motorola
>>(www.motorola.com) have inexpensive DSP Starter Kits (DSK) (TI) or
>>Evaluation Modules (EVM) (Motorola).  The TI C5X DSK (p/n TMDS3200051) costs
>>$99.00 and the Motorola EVM560002 costs $149.00.  I own the later and have
>>the former on order.
>
>Don't forget that you can do serious DSP on general purpose computers without
>a DSP board. Pentiums and the faster 486s rival many dedicated DSPs, especially
>on floating point computations.
>
>Phil
>
>

From karn@unix.ka9q.ampr.org Sun Jun 16 16:51:29 1996
Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA29942 for <hfsig@tapr.org>; Sun, 16 Jun 1996 16:51:25 -0500 (CDT)
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id OAA15153; Sun, 16 Jun 1996 14:51:19 -0700 (PDT)
Date: Sun, 16 Jun 1996 14:51:19 -0700 (PDT)
Message-Id: <199606162151.OAA15153@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: hfsig@tapr.org
In-reply-to: <199606162353.VAA03929@lin01.global.co.za> (zs6awk@global.co.za)
Subject: Re: [HFSIG:1216] Re: DSP Tools
Reply-To: karn@qualcomm.com

Well, the standard Intel programmer's references are pretty good. They
tell you all you really need to know to optimize DSP code on the
Pentium, such as instruction clock counts and considerations on how to
keep the pipelines full.

Phil

From Robert.Glassey@nmp.nokia.com Mon Jun 17 04:27:27 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id EAA02862 for <hfsig@tapr.org>; Mon, 17 Jun 1996 04:27:12 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id MAA10028 for <hfsig@tapr.org>; Mon, 17 Jun 1996 12:26:07 +0300
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA110443452; Mon, 17 Jun 1996 12:24:12 +0300
X-Openmail-Hops: 2
Date: Mon, 17 Jun 96 10:17:35 +0100
Message-Id: <H000029201ddaff7@MHS>
Subject: BTL performance tests
Mime-Version: 1.0
To: hfsig@tapr.org
Content-Type: text/plain; charset=ISO-8859-1; name="BTL"
Content-Transfer-Encoding: 7bit

Hi all,

Over the weekend I did a few performance tests on my PC-
Sound Blaster based DSP RTTY modem (BTL), and compared it 
with my PK232MBX. Here's the results. Any coments welcome.

                                PK232MBX     BTL Ver 0.2

1  Noise performance:             15dB           12dB
   Eb/No for BER=10^-2

2  Adjacent channel rejection (+500Hz 98 baud RTTY)

2a For 3dB rise in 10^-2 Eb/No:
   Square pulse interferer         9dB           30dB
   Raised cosine pulse interferer   -            32dB
   
2b For clean wanted signal, 10^-2 BER:
   Square pulse interferer        16dB           32dB
   Raised cosine pulse interferer  -             35dB
  

Observations:

1. The BER taken includes errors due to both sync
   errors and data bit errors. For both modems
   relative contributions were about 50-50.
   If a bit synchronous mode were used rather than
   asynchronous baudot, BER would be half. My
   measurements show this is equivelent to a 1dB
   improvement in Eb/No for both modems.

2. Two different interferer types were used. Both were
   phase continous FSK, 98 baud baudot, centred 500Hz
   above the wanted signal (wanted 1275/1445, interferer
   1775/1945) Standard RTTY has a square pulse shape
   resulting in  high adjacent channel power. (-30dB @
   500Hz) This limited measurements (and is a real on air
   limit too) However I tried shaping the interferering
   FSK pulses with raised cosine edges (shaped 64 of 82
   samples). ACP was reduced to -45dB @ 500Hz. Using this
   interferer, the true performance of the modem could be
   determined. This shaping reduced the interference RMS
   level to 72% and this was taken into account.

   The minimum signal level without intefernce was found
   to be 1 ADC step peak to peak, with dithering from the
   noise of almost 3 ADC steps peak-peak. (signals were
   calculated in 16 bits then quantised to 8 bits to allow
   noise dithering). At this level performance was still
   12dB Eb/No @ BER 10^-2. This minimum signal level was
   44dB below the inteference level used above. Thus
   quantisation was not a limiting factor in the above
   measurements. Lower levels were possible but Eb/No was
   worsened and quantisation boundries became significant.


Measurement Technique:

1.  Eb/No measurements

Sampling rate was 8KHz

The signal was 45 baud Baudot, phase continuous AFSK, 1275Hz 
space and 1445Hz mark (170Hz shift). RMS to peak ratio = 
0.71

The noise was generated by a 24bit maximum length PRN 
generator (poly=0x8D0000), doing 8 shifts per sample to get 
an 8 bit uniform random noise source. RMS to peak ratio of a 
uniform random noise source = 0.58

I have assumed a uniform distribution is OK since after 
bandpass filtering and integration the noise distribution 
aproaches gausian. (roughly speaking, the noise is averaged 
over the bit period, ie 178 samples, making the noise 
gausian by summation)

For Eb/No calculations I have used the RMS levels at the 
8kHz sample rate.

Peak-peak levels of signal=45 and noise=128 becomes 12db 
Eb/No thus:

Eb/No =  20*log10 ((45/2 * 0.71) / (128/2 * 0.58))
         + 10*log10(4000 Hz) - 10*log10(45 BPS)
      =  12.2 dB


2. Adjacent channel measurements

   The signals are described above.

   The interferer baud rate of 98 baud was chosen to try to
   ovoid synchronisation between the wanted and interferer
   so errors would appear more random, hopefully giving a
   more accurate BER. However it does make the interferer
   wider, but pulse shaping dealt with that. This may not
   be the best method.

   Results are given for two different cases. 1. For a
   3dB rise in the Eb/No required for 10^-2 BER, and
   2. The interference level that gives a BER of 10^-2
   when the wanted signal is clean. These figures show
   respectivly the degradation in weak signal performance,
   and the maximum tolerable adjacent channel signal level
   when the wanted signal is clean.



So, 12dB Eb/No doesn't sound all that hot, does it? But is this what
should be expected for FSK without ECC? Eb/No would be 11dB if a bit
synchronous mode was used. These are for a BER of 10^-2.

Cheers,

Rob





From karn@unix.ka9q.ampr.org Mon Jun 17 05:16:20 1996
Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA04098 for <hfsig@tapr.org>; Mon, 17 Jun 1996 05:16:11 -0500 (CDT)
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id DAA00188; Mon, 17 Jun 1996 03:16:05 -0700 (PDT)
Date: Mon, 17 Jun 1996 03:16:05 -0700 (PDT)
Message-Id: <199606171016.DAA00188@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: hfsig@tapr.org
In-reply-to: <199606130430.VAA01120@servo.qualcomm.com> (karn)
Subject: Re: [HFSIG:1209] Re: Further thoughts on pulse shaping for HF
Reply-To: karn@qualcomm.com

FYI, more about offset QPSK vs conventional QPSK.

It looks as though the advantages of staggered (offset) QPSK are
outweighted by the disadvantages, so I've switched to straight QPSK.

There are two main advantages of offset QPSK: 1) less envelope droop
when the signal is bandlimited, which turns into less sideband
regrowth when the signal is nonlinearly amplified, and 2) less
crosstalk between channels when the carrier phase reference is
inaccurate.

I originally chose SQPSK for reason #2; I don't really care too much
about #1 since I am going to operate in a power-controlled regime
where I assume there'll be a fair amount of transmit headroom most of
the time, hence plenty of linearity.  And even if there were sideband
regrowth it wouldn't be as important a source of interference since
I'm already operating at very low S/N ratios thanks to power control
and coding.

But it turns out that the crosstalk resistance of SQPSK is largely
mitigated by greatly increased pattern-sensitive jitter in the carrier
recovery system.  In other words, although SQPSK has increased carrier
phase jitter tolerance, it inherently increases the jitter of the
recovered carrier which squanders the improved performance.

I couldn't find a precise quantitative formulation for this, but from
what I saw it looks like any gains SQPSK might have (especially at the
very low Es/N0s I'm using) are small or even negative. And the last
straw was that SQPSK is harder to implement than straight QPSK. So
I've switched to straight QPSK.

Phil



From karn@unix.ka9q.ampr.org Mon Jun 17 05:47:56 1996
Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA05064 for <hfsig@tapr.org>; Mon, 17 Jun 1996 05:47:51 -0500 (CDT)
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id DAA00230; Mon, 17 Jun 1996 03:47:44 -0700 (PDT)
Date: Mon, 17 Jun 1996 03:47:44 -0700 (PDT)
Message-Id: <199606171047.DAA00230@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: hfsig@tapr.org
In-reply-to: <1.5.4.16.19960613180138.3ff7efd0@ucs.orst.edu> (message from
	Johan Forrer on Thu, 13 Jun 1996 11:58:25 -0500 (CDT))
Subject: Re: [HFSIG:1212] Re: Further thoughts on pulse shaping for HF
Reply-To: karn@qualcomm.com

>I follow - interesting that SQPSK has that anomaly. I was going to ask
>whether you are using a scrambler as that would reduce the recurrence of
>such a pattern, but your convolutional coding and interleaver will probably
>have the same effect to randomize the pattern.

Re the anomaly I described (certain data patterns killing the SQPSK
phase detector) I'm now not exactly sure that this is real. But it
*does* seem from reading the books that there is a pattern-sensitive
phase jitter in SQPSK that's not present in plain QPSK, and the
problem gets worse when you tightly filter the signal. So that's why
I've switched from SQPSK to plain QPSK. Simplified the code, too.

Re scramblers, no, I'm not scrambling. Yes, the convolutional coding
and interleaving does a pretty good job. It certainly sounds noiselike
except when I send a big block of zeroes, which come out as a tone.
But the loop can track this fine anyway (remember I'm doing one-shot
symbol timing up front).

Re your discussion of decision-directed carrier recovery, it works
great when the Es/N0 is high enough to work without coding. But at the
Es/N0 ratios I'm using with my coding, there are plenty of errors in
the decisions because they're made by simple slicing, without benefit
of any error correction. So many of the phase detector outputs are
wrong (though not most, since the error rate is still less than 50%).
This adds noise to the feedback loop over and above the noise in the
input signal. In the literature this is called "squaring loss"
(although strictly speaking that applies only to BPSK -- in QPSK it
should be called "4th power loss"). Squaring loss is a function of
loop design, Es/N0 and of the loop signal-to-noise ratio.

Squaring loss forces you to use a much narrower loop filter than you'd
otherwise use in order to maintain an acceptably high S/N ratio within
the loop. That means you get pretty sensitive to doppler.

Another good illustration of how trying to conserve bandwidth (e.g.,
by using QPSK instead of BPSK in the first place) often ends up
forcing you to use more power per bit even when it shouldn't -- ideal
QPSK and BPSK (with perfect carrier recovery) have exactly the same
Eb/N0 requirements. I'm still having a hard time getting to within 1
dB of the theoretical code performance in my QPSK modem.

Phil

From LANIER.R.A-@smtpgty.bwi.wec.com  Mon Jun 17 07:25:59 1996
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA09672; Mon, 17 Jun 1996 07:25:51 -0500 (CDT)
Received: from smtpgty.bwi.wec.com by tron.bwi.wec.com; (5.65/1.1.8.2/31May95-0229PM)
	id AA24688; Mon, 17 Jun 1996 07:46:00 -0400
Received: from ccMail by smtpgty.bwi.wec.com
  (IMA Internet Exchange 2.0 Enterprise) id 1C54EE50; Mon, 17 Jun 96 08:26:13 -0400
Mime-Version: 1.0
Date: Mon, 17 Jun 1996 08:16:07 -0400
Message-Id: <1C54EE50.1858@smtpgty.bwi.wec.com>
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-)
To: hfsig@tapr.org, ss@tapr.org
Subject: Sinewave generator source code
Content-Type: multipart/mixed; boundary="IMA.Boundary.273410538"

--IMA.Boundary.273410538
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     For what its worth, I found the article I was looking for (Radio 
     Electronics, October 1991). The author used a C program to generate 
     the data for the EPROM feeding into the DAC. His source code is shown 
     below. I also attached a sample output file to this note. The EPROM is 
     a standard 2716. Of course, the code can be modified to suit your 
     needs.
     
     I intend to use this to produce a LUT (Look Up Table) inside a Xilinx 
     FPGA. I want to use the LUT as the basis for a QPSK modulator. If I 
     can feed serial data into the Xilinx, I can then produce I and Q 
     components and use these as inputs into a custom up/down counter. The 
     output of the counter will feed into the LUT. The output of the LUT 
     would then feed into an external DAC. I'm not sure if this can work, 
     but I will anyone who cares about this now what results I came up 
     with.
     
     73s de
     Tony,  KE4ATO
     
     
     
/* This program calculates the value of the sine function
   offset so that the 4th and 1st quadrants cause a code
   from 0 to 255. Code is generated to fill a 2048 byte prom
   (2716 or equivalent) for a full circle of 2*pi radians.
   Other size memory may be used by changing the value of
   bytes in the declaration table.
*/

#include <stdio.h>
#include <math.h>

main ()
{
  double p=0;           /* phase input to sine function */
       double S=0;      /* output value of the true sine function */
       int s;           /* amplitude truncated to 8 bits */
       double sin();    /* true sine function */
       double pi=3.141592654;
       int addr=0;      /* address of EPROM */
       int bytes=2048;  /* size of EPROM in bytes */
       
       printf("          0    1    2    3    4    5    6    7    8");
       printf("    9    A    B    C    D    E    F  \n");
       while (addr < bytes)
         {
         if (addr % 16 == 0)
           printf("\n%4x   ", addr);
         p = 2.0*pi*( (double) addr)/( (double) bytes);
         S = 127.5*(1.0 + sin(p - pi/2.0));       /* gives 0 at -90 deg */
         s = ( (int) S);                          /* convert to integer */
         if (S - ( (double) s) >= 0.5)            /* rounds if necessary */
           s++;
         printf("   %2x", s);
         addr++;                                  /* increment address */
         }
     return (0);
     }
     
--IMA.Boundary.273410538
Content-Type: text/basic; name="output.txt"
Content-Transfer-Encoding: 7bit
Content-Description: MS-DOS text file
Content-Disposition: attachment; filename="output.txt"

          0   1   2   3   4   5   6   7   8   9   A   B   C   D   E   F  

   0      0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
  10      0   0   0   0   0   0   0   0   0   0   0   0   0   1   1   1
  20      1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1
  30      1   1   1   2   2   2   2   2   2   2   2   2   2   2   2   2
  40      2   3   3   3   3   3   3   3   3   3   3   3   3   4   4   4
  50      4   4   4   4   4   4   4   5   5   5   5   5   5   5   5   5
  60      5   6   6   6   6   6   6   6   6   7   7   7   7   7   7   7
  70      7   8   8   8   8   8   8   8   9   9   9   9   9   9   9   a
  80      a   a   a   a   a   a   b   b   b   b   b   b   c   c   c   c
  90      c   c   d   d   d   d   d   d   e   e   e   e   e   f   f   f
  a0      f   f   f  10  10  10  10  10  11  11  11  11  11  12  12  12
  b0     12  12  13  13  13  13  13  14  14  14  14  14  15  15  15  15
  c0     15  16  16  16  16  17  17  17  17  17  18  18  18  18  19  19
  d0     19  19  1a  1a  1a  1a  1b  1b  1b  1b  1b  1c  1c  1c  1c  1d
  e0     1d  1d  1d  1e  1e  1e  1e  1f  1f  1f  1f  20  20  20  21  21
  f0     21  21  22  22  22  22  23  23  23  23  24  24  24  25  25  25
 100     25  26  26  26  26  27  27  27  28  28  28  28  29  29  29  2a
 110     2a  2a  2a  2b  2b  2b  2c  2c  2c  2d  2d  2d  2d  2e  2e  2e
 120     2f  2f  2f  30  30  30  30  31  31  31  32  32  32  33  33  33
 130     34  34  34  34  35  35  35  36  36  36  37  37  37  38  38  38
 140     39  39  39  3a  3a  3a  3b  3b  3b  3c  3c  3c  3d  3d  3d  3e
 150     3e  3e  3f  3f  3f  40  40  40  41  41  41  42  42  42  43  43
 160     43  44  44  44  45  45  45  46  46  47  47  47  48  48  48  49
 170     49  49  4a  4a  4a  4b  4b  4b  4c  4c  4d  4d  4d  4e  4e  4e
 180     4f  4f  4f  50  50  51  51  51  52  52  52  53  53  53  54  54
 190     55  55  55  56  56  56  57  57  58  58  58  59  59  59  5a  5a
 1a0     5a  5b  5b  5c  5c  5c  5d  5d  5d  5e  5e  5f  5f  5f  60  60
 1b0     61  61  61  62  62  62  63  63  64  64  64  65  65  65  66  66
 1c0     67  67  67  68  68  69  69  69  6a  6a  6a  6b  6b  6c  6c  6c
 1d0     6d  6d  6e  6e  6e  6f  6f  70  70  70  71  71  71  72  72  73
 1e0     73  73  74  74  75  75  75  76  76  77  77  77  78  78  78  79
 1f0     79  7a  7a  7a  7b  7b  7c  7c  7c  7d  7d  7e  7e  7e  7f  7f
 200     80  80  80  81  81  81  82  82  83  83  83  84  84  85  85  85
 210     86  86  87  87  87  88  88  88  89  89  8a  8a  8a  8b  8b  8c
 220     8c  8c  8d  8d  8e  8e  8e  8f  8f  8f  90  90  91  91  91  92
 230     92  93  93  93  94  94  95  95  95  96  96  96  97  97  98  98
 240     98  99  99  9a  9a  9a  9b  9b  9b  9c  9c  9d  9d  9d  9e  9e
 250     9e  9f  9f  a0  a0  a0  a1  a1  a2  a2  a2  a3  a3  a3  a4  a4
 260     a5  a5  a5  a6  a6  a6  a7  a7  a7  a8  a8  a9  a9  a9  aa  aa
 270     aa  ab  ab  ac  ac  ac  ad  ad  ad  ae  ae  ae  af  af  b0  b0
 280     b0  b1  b1  b1  b2  b2  b2  b3  b3  b4  b4  b4  b5  b5  b5  b6
 290     b6  b6  b7  b7  b7  b8  b8  b8  b9  b9  ba  ba  ba  bb  bb  bb
 2a0     bc  bc  bc  bd  bd  bd  be  be  be  bf  bf  bf  c0  c0  c0  c1
 2b0     c1  c1  c2  c2  c2  c3  c3  c3  c4  c4  c4  c5  c5  c5  c6  c6
 2c0     c6  c7  c7  c7  c8  c8  c8  c9  c9  c9  ca  ca  ca  cb  cb  cb
 2d0     cb  cc  cc  cc  cd  cd  cd  ce  ce  ce  cf  cf  cf  cf  d0  d0
 2e0     d0  d1  d1  d1  d2  d2  d2  d2  d3  d3  d3  d4  d4  d4  d5  d5
 2f0     d5  d5  d6  d6  d6  d7  d7  d7  d7  d8  d8  d8  d9  d9  d9  d9
 300     da  da  da  da  db  db  db  dc  dc  dc  dc  dd  dd  dd  dd  de
 310     de  de  de  df  df  df  e0  e0  e0  e0  e1  e1  e1  e1  e2  e2
 320     e2  e2  e3  e3  e3  e3  e4  e4  e4  e4  e4  e5  e5  e5  e5  e6
 330     e6  e6  e6  e7  e7  e7  e7  e8  e8  e8  e8  e8  e9  e9  e9  e9
 340     ea  ea  ea  ea  ea  eb  eb  eb  eb  eb  ec  ec  ec  ec  ec  ed
 350     ed  ed  ed  ed  ee  ee  ee  ee  ee  ef  ef  ef  ef  ef  f0  f0
 360     f0  f0  f0  f0  f1  f1  f1  f1  f1  f2  f2  f2  f2  f2  f2  f3
 370     f3  f3  f3  f3  f3  f4  f4  f4  f4  f4  f4  f5  f5  f5  f5  f5
 380     f5  f5  f6  f6  f6  f6  f6  f6  f6  f7  f7  f7  f7  f7  f7  f7
 390     f8  f8  f8  f8  f8  f8  f8  f8  f9  f9  f9  f9  f9  f9  f9  f9
 3a0     fa  fa  fa  fa  fa  fa  fa  fa  fa  fa  fb  fb  fb  fb  fb  fb
 3b0     fb  fb  fb  fb  fc  fc  fc  fc  fc  fc  fc  fc  fc  fc  fc  fc
 3c0     fd  fd  fd  fd  fd  fd  fd  fd  fd  fd  fd  fd  fd  fd  fe  fe
 3d0     fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe
 3e0     fe  fe  fe  fe  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 3f0     ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 400     ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 410     ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  fe  fe  fe
 420     fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe  fe
 430     fe  fe  fe  fd  fd  fd  fd  fd  fd  fd  fd  fd  fd  fd  fd  fd
 440     fd  fc  fc  fc  fc  fc  fc  fc  fc  fc  fc  fc  fc  fb  fb  fb
 450     fb  fb  fb  fb  fb  fb  fb  fa  fa  fa  fa  fa  fa  fa  fa  fa
 460     fa  f9  f9  f9  f9  f9  f9  f9  f9  f8  f8  f8  f8  f8  f8  f8
 470     f8  f7  f7  f7  f7  f7  f7  f7  f6  f6  f6  f6  f6  f6  f6  f5
 480     f5  f5  f5  f5  f5  f5  f4  f4  f4  f4  f4  f4  f3  f3  f3  f3
 490     f3  f3  f2  f2  f2  f2  f2  f2  f1  f1  f1  f1  f1  f0  f0  f0
 4a0     f0  f0  f0  ef  ef  ef  ef  ef  ee  ee  ee  ee  ee  ed  ed  ed
 4b0     ed  ed  ec  ec  ec  ec  ec  eb  eb  eb  eb  eb  ea  ea  ea  ea
 4c0     ea  e9  e9  e9  e9  e8  e8  e8  e8  e8  e7  e7  e7  e7  e6  e6
 4d0     e6  e6  e5  e5  e5  e5  e4  e4  e4  e4  e4  e3  e3  e3  e3  e2
 4e0     e2  e2  e2  e1  e1  e1  e1  e0  e0  e0  e0  df  df  df  de  de
 4f0     de  de  dd  dd  dd  dd  dc  dc  dc  dc  db  db  db  da  da  da
 500     da  d9  d9  d9  d9  d8  d8  d8  d7  d7  d7  d7  d6  d6  d6  d5
 510     d5  d5  d5  d4  d4  d4  d3  d3  d3  d2  d2  d2  d2  d1  d1  d1
 520     d0  d0  d0  cf  cf  cf  cf  ce  ce  ce  cd  cd  cd  cc  cc  cc
 530     cb  cb  cb  cb  ca  ca  ca  c9  c9  c9  c8  c8  c8  c7  c7  c7
 540     c6  c6  c6  c5  c5  c5  c4  c4  c4  c3  c3  c3  c2  c2  c2  c1
 550     c1  c1  c0  c0  c0  bf  bf  bf  be  be  be  bd  bd  bd  bc  bc
 560     bc  bb  bb  bb  ba  ba  ba  b9  b9  b8  b8  b8  b7  b7  b7  b6
 570     b6  b6  b5  b5  b5  b4  b4  b4  b3  b3  b2  b2  b2  b1  b1  b1
 580     b0  b0  b0  af  af  ae  ae  ae  ad  ad  ad  ac  ac  ac  ab  ab
 590     aa  aa  aa  a9  a9  a9  a8  a8  a7  a7  a7  a6  a6  a6  a5  a5
 5a0     a5  a4  a4  a3  a3  a3  a2  a2  a2  a1  a1  a0  a0  a0  9f  9f
 5b0     9e  9e  9e  9d  9d  9d  9c  9c  9b  9b  9b  9a  9a  9a  99  99
 5c0     98  98  98  97  97  96  96  96  95  95  95  94  94  93  93  93
 5d0     92  92  91  91  91  90  90  8f  8f  8f  8e  8e  8e  8d  8d  8c
 5e0     8c  8c  8b  8b  8a  8a  8a  89  89  88  88  88  87  87  87  86
 5f0     86  85  85  85  84  84  83  83  83  82  82  81  81  81  80  80
 600     7f  7f  7f  7e  7e  7e  7d  7d  7c  7c  7c  7b  7b  7a  7a  7a
 610     79  79  78  78  78  77  77  77  76  76  75  75  75  74  74  73
 620     73  73  72  72  71  71  71  70  70  70  6f  6f  6e  6e  6e  6d
 630     6d  6c  6c  6c  6b  6b  6a  6a  6a  69  69  69  68  68  67  67
 640     67  66  66  65  65  65  64  64  64  63  63  62  62  62  61  61
 650     61  60  60  5f  5f  5f  5e  5e  5d  5d  5d  5c  5c  5c  5b  5b
 660     5a  5a  5a  59  59  59  58  58  58  57  57  56  56  56  55  55
 670     55  54  54  53  53  53  52  52  52  51  51  51  50  50  4f  4f
 680     4f  4e  4e  4e  4d  4d  4d  4c  4c  4b  4b  4b  4a  4a  4a  49
 690     49  49  48  48  48  47  47  47  46  46  45  45  45  44  44  44
 6a0     43  43  43  42  42  42  41  41  41  40  40  40  3f  3f  3f  3e
 6b0     3e  3e  3d  3d  3d  3c  3c  3c  3b  3b  3b  3a  3a  3a  39  39
 6c0     39  38  38  38  37  37  37  36  36  36  35  35  35  34  34  34
 6d0     34  33  33  33  32  32  32  31  31  31  30  30  30  30  2f  2f
 6e0     2f  2e  2e  2e  2d  2d  2d  2d  2c  2c  2c  2b  2b  2b  2a  2a
 6f0     2a  2a  29  29  29  28  28  28  28  27  27  27  26  26  26  26
 700     25  25  25  25  24  24  24  23  23  23  23  22  22  22  22  21
 710     21  21  21  20  20  20  1f  1f  1f  1f  1e  1e  1e  1e  1d  1d
 720     1d  1d  1c  1c  1c  1c  1b  1b  1b  1b  1b  1a  1a  1a  1a  19
 730     19  19  19  18  18  18  18  17  17  17  17  17  16  16  16  16
 740     15  15  15  15  15  14  14  14  14  14  13  13  13  13  13  12
 750     12  12  12  12  11  11  11  11  11  10  10  10  10  10   f   f
 760      f   f   f   f   e   e   e   e   e   d   d   d   d   d   d   c
 770      c   c   c   c   c   b   b   b   b   b   b   a   a   a   a   a
 780      a   a   9   9   9   9   9   9   9   8   8   8   8   8   8   8
 790      7   7   7   7   7   7   7   7   6   6   6   6   6   6   6   6
 7a0      5   5   5   5   5   5   5   5   5   5   4   4   4   4   4   4
 7b0      4   4   4   4   3   3   3   3   3   3   3   3   3   3   3   3
 7c0      2   2   2   2   2   2   2   2   2   2   2   2   2   2   1   1
 7d0      1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1
 7e0      1   1   1   1   0   0   0   0   0   0   0   0   0   0   0   0
 7f0      0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
--IMA.Boundary.273410538--
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Hi Robert,

Congratulations! - Nice writeup. 

Is the program generally available yet, or what are your future plans.

Keep up the good work.

--Johan



On Mon, 17 Jun 1996 Robert.Glassey@nmp.nokia.com wrote:

> Hi all,
> 
> Over the weekend I did a few performance tests on my PC-
> Sound Blaster based DSP RTTY modem (BTL), and compared it 
> with my PK232MBX. Here's the results. Any coments welcome.
> 
>                                 PK232MBX     BTL Ver 0.2
> 
> 1  Noise performance:             15dB           12dB
>    Eb/No for BER=10^-2
> 
> 2  Adjacent channel rejection (+500Hz 98 baud RTTY)
> 
> 2a For 3dB rise in 10^-2 Eb/No:
>    Square pulse interferer         9dB           30dB
>    Raised cosine pulse interferer   -            32dB
>    
> 2b For clean wanted signal, 10^-2 BER:
>    Square pulse interferer        16dB           32dB
>    Raised cosine pulse interferer  -             35dB
>   
> 
> Observations:
> 
> 1. The BER taken includes errors due to both sync
>    errors and data bit errors. For both modems
>    relative contributions were about 50-50.
>    If a bit synchronous mode were used rather than
>    asynchronous baudot, BER would be half. My
>    measurements show this is equivelent to a 1dB
>    improvement in Eb/No for both modems.
> 
> 2. Two different interferer types were used. Both were
>    phase continous FSK, 98 baud baudot, centred 500Hz
>    above the wanted signal (wanted 1275/1445, interferer
>    1775/1945) Standard RTTY has a square pulse shape
>    resulting in  high adjacent channel power. (-30dB @
>    500Hz) This limited measurements (and is a real on air
>    limit too) However I tried shaping the interferering
>    FSK pulses with raised cosine edges (shaped 64 of 82
>    samples). ACP was reduced to -45dB @ 500Hz. Using this
>    interferer, the true performance of the modem could be
>    determined. This shaping reduced the interference RMS
>    level to 72% and this was taken into account.
> 
>    The minimum signal level without intefernce was found
>    to be 1 ADC step peak to peak, with dithering from the
>    noise of almost 3 ADC steps peak-peak. (signals were
>    calculated in 16 bits then quantised to 8 bits to allow
>    noise dithering). At this level performance was still
>    12dB Eb/No @ BER 10^-2. This minimum signal level was
>    44dB below the inteference level used above. Thus
>    quantisation was not a limiting factor in the above
>    measurements. Lower levels were possible but Eb/No was
>    worsened and quantisation boundries became significant.
> 
> 
> Measurement Technique:
> 
> 1.  Eb/No measurements
> 
> Sampling rate was 8KHz
> 
> The signal was 45 baud Baudot, phase continuous AFSK, 1275Hz 
> space and 1445Hz mark (170Hz shift). RMS to peak ratio = 
> 0.71
> 
> The noise was generated by a 24bit maximum length PRN 
> generator (poly=0x8D0000), doing 8 shifts per sample to get 
> an 8 bit uniform random noise source. RMS to peak ratio of a 
> uniform random noise source = 0.58
> 
> I have assumed a uniform distribution is OK since after 
> bandpass filtering and integration the noise distribution 
> aproaches gausian. (roughly speaking, the noise is averaged 
> over the bit period, ie 178 samples, making the noise 
> gausian by summation)
> 
> For Eb/No calculations I have used the RMS levels at the 
> 8kHz sample rate.
> 
> Peak-peak levels of signal=45 and noise=128 becomes 12db 
> Eb/No thus:
> 
> Eb/No =  20*log10 ((45/2 * 0.71) / (128/2 * 0.58))
>          + 10*log10(4000 Hz) - 10*log10(45 BPS)
>       =  12.2 dB
> 
> 
> 2. Adjacent channel measurements
> 
>    The signals are described above.
> 
>    The interferer baud rate of 98 baud was chosen to try to
>    ovoid synchronisation between the wanted and interferer
>    so errors would appear more random, hopefully giving a
>    more accurate BER. However it does make the interferer
>    wider, but pulse shaping dealt with that. This may not
>    be the best method.
> 
>    Results are given for two different cases. 1. For a
>    3dB rise in the Eb/No required for 10^-2 BER, and
>    2. The interference level that gives a BER of 10^-2
>    when the wanted signal is clean. These figures show
>    respectivly the degradation in weak signal performance,
>    and the maximum tolerable adjacent channel signal level
>    when the wanted signal is clean.
> 
> 
> 
> So, 12dB Eb/No doesn't sound all that hot, does it? But is this what
> should be expected for FSK without ECC? Eb/No would be 11dB if a bit
> synchronous mode was used. These are for a BER of 10^-2.
> 
> Cheers,
> 
> Rob
> 
> 
> 
> 
> 
> 
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Hi Phil,


On Mon, 17 Jun 1996, Phil Karn wrote:

> FYI, more about offset QPSK vs conventional QPSK.
> 
> It looks as though the advantages of staggered (offset) QPSK are
> outweighted by the disadvantages, so I've switched to straight QPSK.
> 
> There are two main advantages of offset QPSK: 1) less envelope droop
> when the signal is bandlimited, which turns into less sideband
> regrowth when the signal is nonlinearly amplified, and 2) less
> crosstalk between channels when the carrier phase reference is
> inaccurate.
> 
> I originally chose SQPSK for reason #2; I don't really care too much
> about #1 since I am going to operate in a power-controlled regime
> where I assume there'll be a fair amount of transmit headroom most of
> the time, hence plenty of linearity.  And even if there were sideband
> regrowth it wouldn't be as important a source of interference since
> I'm already operating at very low S/N ratios thanks to power control
> and coding.
> 
> But it turns out that the crosstalk resistance of SQPSK is largely
> mitigated by greatly increased pattern-sensitive jitter in the carrier
> recovery system.  In other words, although SQPSK has increased carrier
> phase jitter tolerance, it inherently increases the jitter of the
> recovered carrier which squanders the improved performance.
> 
> I couldn't find a precise quantitative formulation for this, but from
> what I saw it looks like any gains SQPSK might have (especially at the
> very low Es/N0s I'm using) are small or even negative. And the last
> straw was that SQPSK is harder to implement than straight QPSK. So
> I've switched to straight QPSK.
> 
> Phil
> 
> 
> 
>

Your initial considerations for using the offset format seems quite valid 
if one perhaps can overcome the side effects you mention.

About QPSK: The clean compact signal format that I see here is very 
encouraging. Using raised cosine pulse shaping is a bit of a hassle, but 
well worth it. I think if one can address the issue of non-linear 
amplification, that this may not be a bad way to go. 

One other thing that I experimented with this weekend was 
non-coherent detection of DQPSK. After getting it to work, I was quite 
surprized at how well it worked out. The constellations were tight 
and text-book style. There is the expected recovery loss (i.e. lower 
dynamic range) by giving up carrier extraction, however, I am of the 
opinion that in the end it may work out best for HF especially 
when used in conjunction with good coding.

The issue about the use of an unmodulated carrier for doppler compensation:
One of the first things that I do in my modem is to create an analytic 
signal, with a frequency shifter stage built into the front end. The 
frequency shifter is controlled by a doppler extractor algorithm. 
Doppler estimation is modelled as a second order AR process derived from 
the special unmodulated carrier after filtering by a narrow-band filter. 
The frequency estimate is obtained solving two simulataneous equations 
(Yule-Walker). There are provisions to deal with times when the carrier has 
faded - pretty much a very heavy damped system similar to what I do with 
clock extraction. 

Good luck with your project.

--Johan
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Hi Bob--

In a message dated 96-06-17 06:48:58 EDT, you write:

>Hi all,
>
>Over the weekend I did a few performance tests on my PC-
>Sound Blaster based DSP RTTY modem (BTL), and compared it 
>with my PK232MBX. Here's the results. Any coments welcome.
>
>

Very interesting weekend project you had there!  I am not familiar with the
BTL software you mentioned. Who is the author, and where is it available? Can
the hardware interupt and io address of the sound card be changed so that it
can be run on a notebook computer that has a  "Sound Blaster compatible"
chip? 

I have a Motorola DSP56002EVM board, and would like to run similar tests... 

--73's de Bob Carlson, n0aot@amsat.org
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Received: from smtpgty.bwi.wec.com by tron.bwi.wec.com; (5.65/1.1.8.2/31May95-0229PM)
	id AA31591; Mon, 17 Jun 1996 14:20:15 -0400
Received: from ccMail by smtpgty.bwi.wec.com
  (IMA Internet Exchange 2.0 Enterprise) id 1C5AC3F0; Mon, 17 Jun 96 15:04:31 -0400
Mime-Version: 1.0
Date: Mon, 17 Jun 1996 14:56:48 -0400
Message-Id: <1C5AC3F0.1858@smtpgty.bwi.wec.com>
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-)
Subject: Re: [HFSIG:1222] Re: BTL performance tests
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     Johan,
     
     I think you have me confused with someone else. I didn't write the 
     text below - wish I did though. Its pretty impressive!
     
     73s de
     Tony,  KE4ATO
     
     P.S. My first name is Robert, but I go by Tony (middle name Anthony) 
     in all of my correspondence.


______________________________ Reply Separator _________________________________
Subject: [HFSIG:1222] Re: BTL performance tests
Author:  hfsig@tapr.org at BALT.SMTP
Date:    6/17/96 10:49 AM


Hi Robert,
     
Congratulations! - Nice writeup. 
     
Is the program generally available yet, or what are your future plans.
     
Keep up the good work.
     
--Johan
     
     
     
On Mon, 17 Jun 1996 Robert.Glassey@nmp.nokia.com wrote:
     
> Hi all,
> 
> Over the weekend I did a few performance tests on my PC- 
> Sound Blaster based DSP RTTY modem (BTL), and compared it 
> with my PK232MBX. Here's the results. Any coments welcome. 
> 
>                                 PK232MBX     BTL Ver 0.2 
> 
> 1  Noise performance:             15dB           12dB 
>    Eb/No for BER=10^-2
> 
> 2  Adjacent channel rejection (+500Hz 98 baud RTTY) 
> 
> 2a For 3dB rise in 10^-2 Eb/No:
>    Square pulse interferer         9dB           30dB 
>    Raised cosine pulse interferer   -            32dB 
>    
> 2b For clean wanted signal, 10^-2 BER:
>    Square pulse interferer        16dB           32dB 
>    Raised cosine pulse interferer  -             35dB 
>   
> 
> Observations:
> 
> 1. The BER taken includes errors due to both sync 
>    errors and data bit errors. For both modems
>    relative contributions were about 50-50.
>    If a bit synchronous mode were used rather than 
>    asynchronous baudot, BER would be half. My
>    measurements show this is equivelent to a 1dB 
>    improvement in Eb/No for both modems.
> 
> 2. Two different interferer types were used. Both were 
>    phase continous FSK, 98 baud baudot, centred 500Hz
>    above the wanted signal (wanted 1275/1445, interferer 
>    1775/1945) Standard RTTY has a square pulse shape
>    resulting in  high adjacent channel power. (-30dB @
>    500Hz) This limited measurements (and is a real on air 
>    limit too) However I tried shaping the interferering
>    FSK pulses with raised cosine edges (shaped 64 of 82
>    samples). ACP was reduced to -45dB @ 500Hz. Using this 
>    interferer, the true performance of the modem could be 
>    determined. This shaping reduced the interference RMS 
>    level to 72% and this was taken into account.
> 
>    The minimum signal level without intefernce was found 
>    to be 1 ADC step peak to peak, with dithering from the 
>    noise of almost 3 ADC steps peak-peak. (signals were
>    calculated in 16 bits then quantised to 8 bits to allow 
>    noise dithering). At this level performance was still
>    12dB Eb/No @ BER 10^-2. This minimum signal level was 
>    44dB below the inteference level used above. Thus
>    quantisation was not a limiting factor in the above
>    measurements. Lower levels were possible but Eb/No was 
>    worsened and quantisation boundries became significant. 
> 
> 
> Measurement Technique:
> 
> 1.  Eb/No measurements
> 
> Sampling rate was 8KHz
> 
> The signal was 45 baud Baudot, phase continuous AFSK, 1275Hz 
> space and 1445Hz mark (170Hz shift). RMS to peak ratio = 
> 0.71
> 
> The noise was generated by a 24bit maximum length PRN 
> generator (poly=0x8D0000), doing 8 shifts per sample to get 
> an 8 bit uniform random noise source. RMS to peak ratio of a 
> uniform random noise source = 0.58
> 
> I have assumed a uniform distribution is OK since after 
> bandpass filtering and integration the noise distribution 
> aproaches gausian. (roughly speaking, the noise is averaged 
> over the bit period, ie 178 samples, making the noise 
> gausian by summation)
> 
> For Eb/No calculations I have used the RMS levels at the 
> 8kHz sample rate.
> 
> Peak-peak levels of signal=45 and noise=128 becomes 12db 
> Eb/No thus:
> 
> Eb/No =  20*log10 ((45/2 * 0.71) / (128/2 * 0.58)) 
>          + 10*log10(4000 Hz) - 10*log10(45 BPS)
>       =  12.2 dB
> 
> 
> 2. Adjacent channel measurements
> 
>    The signals are described above. 
> 
>    The interferer baud rate of 98 baud was chosen to try to 
>    ovoid synchronisation between the wanted and interferer 
>    so errors would appear more random, hopefully giving a
>    more accurate BER. However it does make the interferer 
>    wider, but pulse shaping dealt with that. This may not 
>    be the best method.
> 
>    Results are given for two different cases. 1. For a 
>    3dB rise in the Eb/No required for 10^-2 BER, and
>    2. The interference level that gives a BER of 10^-2 
>    when the wanted signal is clean. These figures show
>    respectivly the degradation in weak signal performance, 
>    and the maximum tolerable adjacent channel signal level 
>    when the wanted signal is clean.
> 
> 
> 
> So, 12dB Eb/No doesn't sound all that hot, does it? But is this what 
> should be expected for FSK without ECC? Eb/No would be 11dB if a bit 
> synchronous mode was used. These are for a BER of 10^-2.
> 
> Cheers,
> 
> Rob
> 
> 
> 
> 
> 
> 
     

From LANIER.R.A-@smtpgty.bwi.wec.com  Mon Jun 17 16:22:47 1996
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA03634 for <hfsig@tapr.org>; Mon, 17 Jun 1996 16:21:57 -0500 (CDT)
Received: from smtpgty.bwi.wec.com by tron.bwi.wec.com; (5.65/1.1.8.2/31May95-0229PM)
	id AA23940; Mon, 17 Jun 1996 16:36:09 -0400
Received: from ccMail by smtpgty.bwi.wec.com
  (IMA Internet Exchange 2.0 Enterprise) id 1C5CC660; Mon, 17 Jun 96 17:21:42 -0400
Mime-Version: 1.0
Date: Mon, 17 Jun 1996 17:19:52 -0400
Message-Id: <1C5CC660.1858@smtpgty.bwi.wec.com>
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-)
Subject: Re: [HFSIG:1224] Re: BTL performance tests
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     I am not the author of this software project! I don't know how my name 
     got mixed up.
     
     Tony,  KE4ATO


______________________________ Reply Separator _________________________________
Subject: [HFSIG:1224] Re: BTL performance tests
Author:  hfsig@tapr.org at BALT.SMTP
Date:    6/17/96 1:15 PM


Hi Bob--
     
In a message dated 96-06-17 06:48:58 EDT, you write:
     
>Hi all,
>
>Over the weekend I did a few performance tests on my PC- 
>Sound Blaster based DSP RTTY modem (BTL), and compared it 
>with my PK232MBX. Here's the results. Any coments welcome. 
>
>
     
Very interesting weekend project you had there!  I am not familiar with the 
BTL software you mentioned. Who is the author, and where is it available? Can 
the hardware interupt and io address of the sound card be changed so that it 
can be run on a notebook computer that has a  "Sound Blaster compatible" 
chip? 
     
I have a Motorola DSP56002EVM board, and would like to run similar tests... 
     
--73's de Bob Carlson, n0aot@amsat.org
     

From karn@qualcomm.com Mon Jun 17 22:37:52 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA17713 for <hfsig@tapr.org>; Mon, 17 Jun 1996 22:37:43 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id UAA02588; Mon, 17 Jun 1996 20:37:10 -0700 (PDT)
Date: Mon, 17 Jun 1996 20:37:10 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606180337.UAA02588@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <Pine.OSF.3.91.960617084032.20926B-100000@ucs.orst.edu> (message from Johan Forrer on Mon, 17 Jun 1996 11:22:58 -0500 (CDT))

Subject: Re: [HFSIG:1223] Re: Further thoughts on pulse shaping for HF

Johan,

Noncoherent schemes have a lot going for them on fading, dispersive
channels.  Not only because it's hard to extract a carrier phase
that's rapidly changing, but also because the dynamic range of the
fading tends to swamp the relatively small Eb/N0 ratio differences
between coherent and noncoherent modulation that are otherwise
important on severely power-constrained nonfading AWGN channels.

The three most important things on a fading channel are diversity,
diversity and diversity. :-) Diversity can be in time, space or
frequency.  Coding helps promotes diversity, particularly in time by
spreading out the influence of one data bit over many symbols (only
some of which may get through).  And even QPSK can help by simply
creating more slots for those coded symbols in the first place.

Phil

From karn@qualcomm.com Mon Jun 17 22:58:10 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA18215 for <hfsig@tapr.org>; Mon, 17 Jun 1996 22:58:07 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id UAA02630; Mon, 17 Jun 1996 20:57:35 -0700 (PDT)
Date: Mon, 17 Jun 1996 20:57:35 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606180357.UAA02630@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <Pine.OSF.3.91.960617084032.20926B-100000@ucs.orst.edu> (message from Johan Forrer on Mon, 17 Jun 1996 11:22:58 -0500 (CDT))
Subject: Re: [HFSIG:1223] Re: Further thoughts on pulse shaping for HF

>One of the first things that I do in my modem is to create an analytic 
>signal, with a frequency shifter stage built into the front end. The 
>frequency shifter is controlled by a doppler extractor algorithm. 

This is exactly my approach also. The frequency shifter is at present
set to a fixed value based on the estimated frequency of the carrier
burst in the packet preamble.  This assumes that any residual error is
small compared to the data rate (it is), so it can be tracked out
after filtering and downsampling from 8x to 1x the symbol rate. (The
downsampling starts once I have obtained one-shot symbol sync from the
preamble).

Although all further processing has to be done with complex
arithmetic, performance-wise I think I'm still ahead after the
downsampling.

Eventually I will probably have to add a doppler chirper to the
frequency shifter driven by an orbit tracking routine. This is
relatively straightforward given accurate orbital elements, time and
station location.

Phil


From forrerj@ucs.orst.edu Mon Jun 17 23:54:01 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id XAA21367 for <hfsig@tapr.org>; Mon, 17 Jun 1996 23:53:53 -0500 (CDT)
Received: from p08.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA18775; Mon, 17 Jun 1996 21:53:44 -0700
Message-Id: <1.5.4.16.19960618055458.4c9f67fc@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 17 Jun 1996 21:54:58 -0800
To: hfsig@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Re: [HFSIG:1225] Re: BTL performance tests

At 02:21 PM 6/17/96 -0500, you wrote:
>     Johan,
>     
>     I think you have me confused with someone else. I didn't write the 
>     text below - wish I did though. Its pretty impressive!
>     
>     73s de
>     Tony,  KE4ATO
>     
>     P.S. My first name is Robert, but I go by Tony (middle name Anthony) 
>     in all of my correspondence.
>
>

Strange things do happen :-) 

My reply was directed at Robert (Rob) Glassey's fine work (please see below)
- somehow we got our lines crossed - no harm done. Still a nice piece of
work Rob.

--Johan


>Hi Robert,
>     
>Congratulations! - Nice writeup. 
>     
>Is the program generally available yet, or what are your future plans.
>     
>Keep up the good work.
>     

...... some lines deleted 

>     
>     
>On Mon, 17 Jun 1996 Robert.Glassey@nmp.nokia.com wrote:
>     

...... some more lines deleted 

From Robert.Glassey@nmp.nokia.com Tue Jun 18 04:22:31 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id EAA03763 for <hfsig@tapr.org>; Tue, 18 Jun 1996 04:22:27 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id MAA27649 for <hfsig@tapr.org>; Tue, 18 Jun 1996 12:21:49 +0300
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA262409595; Tue, 18 Jun 1996 12:19:55 +0300
X-Openmail-Hops: 2
Date: Tue, 18 Jun 96 10:15:50 +0100
Message-Id: <H000029201dfc18f@MHS>
In-Reply-To: <Pine.OSF.3.91.960617083834.20926A-100000@ucs.orst.edu>
Subject: [HFSIG:1222] Re: BTL performance tests
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org

> Hi Robert,
> 
> Congratulations! - Nice writeup. 
> 
> Is the program generally available yet, or what are your future plans.
> 
> Keep up the good work.
> 
> --Johan
> 
> 
> On Mon, 17 Jun 1996 Robert.Glassey@nmp.nokia.com wrote:
> 
> > Hi all,
> > 
> > Over the weekend I did a few performance tests on my PC-
> > Sound Blaster based DSP RTTY modem (BTL), and compared it 
> > with my PK232MBX. Here's the results. Any coments welcome.

Thanks, Its still on beta test, with V0.2beta out very soon (I hope)
- Sorry to those testers still waiting for the next version,
unfortunatly my weekend projects don't always get the time they deserve.

The release version 1.0, should be ready in a copule of weeks. This
version recieves standard baudot only, with variable baud, shift and
centre frequency, plus a few other features.

My next release (could be 6 months away) will have TX, and a wide shift
mode for comercial news services etc. I hope to include AMTOR FEC and
ARQ modes as well. Plus any improvements in performance I can find,
probably a bit-synchronous demod mode (for standard 7.5 bit baudot), and
maybe an improved tuning indicator, auto tuning, and mode/baud
detection.

This was my intention from the start for a first release, but things
have taken a while, and I think people want it as it is right now.

Ultimatly I would like to use BTL as a platform for more complex modes
such as PACTOR II or Clover II or other multicarrier modes that may be
developed through HFSIG. I'm also keen to implement very low SNR modes,
such as DBPSK with heaps of ECC using a type II hybrid ARQ protocol.

I intend to release up to version 2 as public domain freeware.


Cheers,

Rob Glassey, G0VTQ

From BRYD@KIDD.CO.ZA Tue Jun 18 04:26:46 1996
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id EAA04022 for <hfsig@tapr.org>; Tue, 18 Jun 1996 04:26:41 -0500 (CDT)
Received: from KIDD.CO.ZA by igw01 with smtp
	(Smail3.1.29.1 #3) id m0uVx3H-000PAWC; Tue, 18 Jun 96 11:26 GMT+0200
Received: from KenMail-Message_Server by KIDD.CO.ZA
	with Novell_GroupWise; Tue, 18 Jun 1996 11:33:08 +0200
Message-Id: <s1c693f3.043@KIDD.CO.ZA>
X-Mailer: Novell GroupWise 4.1
Date: Tue, 18 Jun 1996 11:26:45 +0200
From: Danie Brynard <BRYD@KIDD.CO.ZA>
To: hfsig@tapr.org
Subject:  Well, the standard Intel programmer's references are pretty
	
          good. They tell you all you really need 

Well, the standard Intel programmer's references are pretty good. They tell you all you really need to know to
optimize DSP code on the
Pentium, such as instruction clock counts and considerations on how to keep the pipelines full.

Phil

I see. Thanks. 73 danie

From Robert.Glassey@nmp.nokia.com Tue Jun 18 05:38:14 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id FAA05769 for <hfsig@tapr.org>; Tue, 18 Jun 1996 05:38:11 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id MAA29755 for <hfsig@tapr.org>; Tue, 18 Jun 1996 12:52:02 +0300
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA298861408; Tue, 18 Jun 1996 12:50:08 +0300
X-Openmail-Hops: 2
Date: Tue, 18 Jun 96 10:45:45 +0100
Message-Id: <H000029201dfdd45@MHS>
In-Reply-To: <960617140256_558017278@emout09.mail.aol.com>
Subject: [HFSIG:1224] Re: BTL performance tests
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org

> Hi Bob--
> 
> In a message dated 96-06-17 06:48:58 EDT, you write:
> 
> >Hi all,
> >
> >Over the weekend I did a few performance tests on my PC-
> >Sound Blaster based DSP RTTY modem (BTL), and compared it 
> >with my PK232MBX. Here's the results. Any coments welcome.
> >
> >
> 
> Very interesting weekend project you had there!  I am not familiar 
> with the BTL software you mentioned. Who is the author, and where is
> it available? Can the hardware interupt and io address of the sound
> card be changed so that it can be run on a notebook computer that has
> a  "Sound Blaster compatible" chip? 
> 
> I have a Motorola DSP56002EVM board, and would like to run similar
> tests... 
> 
> --73's de Bob Carlson, n0aot@amsat.org

Hi Bob,

BTL is not on general release yet, but soon will be. BTL is my 'baby'
and has taken me since around August last year to write (very slowly
since its a weekend project). When released, I hope to get it onto an
FTP site somewhere, maybe the TAPR site? This version is FREE!

Soundblaster parameters are user configurable, and it accepts the
standard sound blaster enviroment variable BLASTER=....

It should work on any soundblaster compatible from the original v1.0 to
the latest AWE32.

It should run on your notebook if its fast enough. To date, the slowest
machine I've tried is a 486sx25 and that works fine. If speed is a
problem I may release a cut down 1.5 version which should run faster.

The tests were done with a C program that generated test signals plus
noise that I used as my signal generator for the tests.

The test signal was played on the SB for the PK 232, and taken directly
from disk, in real time, for the BTL tests, by substituting the
soundblaster DMA for a double buffered disk routine.

I also have a DAT recorder that I have used in the past for testing.
I'll have to repeat these BTL tests using recorded signals.

Cheers,

Rob, G0VTQ

From BRYD@KIDD.CO.ZA Wed Jun 19 08:46:09 1996
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA09757 for <hfsig@tapr.org>; Wed, 19 Jun 1996 08:46:04 -0500 (CDT)
Received: from KIDD.CO.ZA by igw01 with smtp
	(Smail3.1.29.1 #3) id m0uWNsX-000PHoC; Wed, 19 Jun 96 16:05 GMT+0200
Received: from KenMail-Message_Server by KIDD.CO.ZA
	with Novell_GroupWise; Wed, 19 Jun 1996 15:52:34 +0200
Message-Id: <s1c82242.070@KIDD.CO.ZA>
X-Mailer: Novell GroupWise 4.1
Date: Wed, 19 Jun 1996 15:46:16 +0200
From: Danie Brynard <BRYD@KIDD.CO.ZA>
To: hfsig@tapr.org
Subject:  


I also have a DAT recorder that I have used in the past for testing.
I'll have to repeat these BTL tests using recorded signals.

---------------------------------------------------------------------------
Bob how well does the DAT recorder work and is it not too expensive ? I also have a need for soemthing like that.
It is difficult with the sat signals as they pass very quickly...no time to recompile and download hi :-)

danie zs6awk


From Robert.Glassey@nmp.nokia.com Wed Jun 19 10:34:23 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA16025 for <hfsig@tapr.org>; Wed, 19 Jun 1996 10:34:15 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id SAA26250 for <hfsig@tapr.org>; Wed, 19 Jun 1996 18:33:35 +0300
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA104938299; Wed, 19 Jun 1996 18:31:39 +0300
X-Openmail-Hops: 2
Date: Wed, 19 Jun 96 16:30:26 +0100
Message-Id: <H000029201e2ac42@MHS>
In-Reply-To: <s1c82242.070@KIDD.CO.ZA>
Subject: [HFSIG:1233]
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org

>> I also have a DAT recorder that I have used in the past for testing.
>> Bob how well does the DAT recorder work and is it not too expensive ?
> I also have a need for soemthing like that.
> It is difficult with the sat signals as they pass very quickly...no
> time to recompile and download hi :-)
> 
> danie zs6awk

Hi Danie,

They work very well, even preserve timing on amtor/pactor. They are a
little pricy, mine cost around $650 US, but it is a walkman model, (Sony
TCD-D7). A hi-fi component style version should be cheaper. I find the
walkman handy for taking a known test signal from one PC to another for
testing on different sound cards etc. They are also usefull for
recording a live QSO then replaying it over and over while modifying the
program to test with a known signal. They are also available second hand
occasionally, but beware of older models, reliability was a problem with
them, and they're probably on their last legs now if they haven't
already died.

If you have a sound blaster your best bet (and cheapest) would be to
record the satilite on disk the play it back to the DSP. 10 minutes will
take about 5MB. You may need make your DSP code more independent of the
PC (buffer output etc) or get another PC!

Its actually quite simple to write a C program to play the sound file
and act as a dumb terminal at the same time.

73's

Rob,

G0VTQ

From forrerj@ucs.orst.edu Wed Jun 19 11:17:09 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA17643 for <hfsig@tapr.org>; Wed, 19 Jun 1996 11:17:06 -0500 (CDT)
Received: from p00.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA19123; Wed, 19 Jun 1996 09:16:55 -0700
Message-Id: <1.5.4.16.19960619171812.3f8ffe56@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 19 Jun 1996 09:18:12 -0800
To: hfsig@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Re: [HFSIG:1228] Re: Further thoughts on pulse shaping for HF

Phil,

......

>
>Although all further processing has to be done with complex
>arithmetic, performance-wise I think I'm still ahead after the
>downsampling.
>
>Eventually I will probably have to add a doppler chirper to the
>frequency shifter driven by an orbit tracking routine. This is
>relatively straightforward given accurate orbital elements, time and
>station location.

Sounds quite involved - fortunate that you have such a nice closed-form
predition method. I was wondering; are there any residual effects to deal
with due to spin motion of the satellite? some higher than doppler phasing
effects or does the circular polarized antennas take care of it? 

Re: Doppler tracking on HF: 
I'm looking into following reasonably fast-changing doppler effects, i.e., a
fraction of a symbol time. The method that I'm interested in for estimating
doppler comes from LPC methodology and the ideas are well developed -
extracting pitch, or in other words specifying a filter from the signal. I'm
not sure how well it will work for what I am doing, but I'm willing to give
it a chance. 

Anyway, the modem will have to go on the back burner for a while - something
else has come up that needs to be done.

--Johan

From forrerj@ucs.orst.edu Wed Jun 19 11:17:09 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA17644 for <hfsig@tapr.org>; Wed, 19 Jun 1996 11:17:06 -0500 (CDT)
Received: from p00.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA08169; Wed, 19 Jun 1996 09:17:00 -0700
Message-Id: <1.5.4.16.19960619171816.0d271ab0@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 19 Jun 1996 09:18:16 -0800
To: hfsig@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Re: [HFSIG:1230] Re: BTL performance tests

Hi Rob,



>Ultimatly I would like to use BTL as a platform for more complex modes
>such as PACTOR II or Clover II or other multicarrier modes that may be
>developed through HFSIG. I'm also keen to implement very low SNR modes,
>such as DBPSK with heaps of ECC using a type II hybrid ARQ protocol.
>
>I intend to release up to version 2 as public domain freeware.
>
>
>Cheers,
>
>Rob Glassey, G0VTQ
>
>

Excellent!

Would you consider uploading a program version to HFSIG? If you do, also
please provide a ".txt" version for the folks that browse the files with
their web browser.

Keep us posted on your progress - sounds like good stuff.

--Johan

From karn@qualcomm.com Wed Jun 19 18:27:25 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA06837 for <hfsig@tapr.org>; Wed, 19 Jun 1996 18:27:22 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id QAA23790; Wed, 19 Jun 1996 16:26:49 -0700 (PDT)
Date: Wed, 19 Jun 1996 16:26:49 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199606192326.QAA23790@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <1.5.4.16.19960619171812.3f8ffe56@ucs.orst.edu> (message from Johan Forrer on Wed, 19 Jun 1996 11:21:34 -0500 (CDT))
Subject: Re: [HFSIG:1235] Re: Further thoughts on pulse shaping for HF

>Sounds quite involved - fortunate that you have such a nice closed-form
>predition method. I was wondering; are there any residual effects to deal
>with due to spin motion of the satellite? some higher than doppler phasing
>effects or does the circular polarized antennas take care of it? 

As a matter of fact, yes. James Miller has pointed out that the S-band
antenna on AO-13 is not mounted along the center of mass, so if the
antennas are not lined up on earth the antenna moves to and fro along
the line of sight as the spacecraft spins. This introduces a
sinusoidal doppler shift on the order of 5 Hz, which is significant to
me.

Of course, this may be somewhat academic as I probably won't get this
stuff on mode S before AO-13 burns up, and P3D is 3-axis stabilized.

Phil

From BRYD@KIDD.CO.ZA Thu Jun 20 06:29:12 1996
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id GAA11730 for <hfsig@tapr.org>; Thu, 20 Jun 1996 06:29:02 -0500 (CDT)
Received: from KIDD.CO.ZA by igw01 with smtp
	(Smail3.1.29.1 #3) id m0uWhv0-000PLoC; Thu, 20 Jun 96 13:28 GMT+0200
Received: from KenMail-Message_Server by KIDD.CO.ZA
	with Novell_GroupWise; Thu, 20 Jun 1996 13:35:46 +0200
Message-Id: <s1c953b2.040@KIDD.CO.ZA>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 20 Jun 1996 13:28:28 +0200
From: Danie Brynard <BRYD@KIDD.CO.ZA>
To: hfsig@tapr.org
Subject:  


If you have a sound blaster your best bet (and cheapest) would be to record the satilite on disk the play it back to
the DSP. 10 minutes will take about 5MB. You may need make your DSP code more independent of the
PC (buffer output etc) or get another PC!

Its actually quite simple to write a C program to play the sound file and act as a dumb terminal at the same time.
=============================
I see. Yes I do have another PC. BTW what is the bandwidth of the DAT tape ? I suppose it has now phase
distorsion ie wow & flutter ?

danie


From LANIER.R.A-@smtpgty.bwi.wec.com  Thu Jun 20 10:41:54 1996
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA20149 for <hfsig@tapr.org>; Thu, 20 Jun 1996 10:41:49 -0500 (CDT)
Received: from smtpgty.bwi.wec.com by tron.bwi.wec.com; (5.65/1.1.8.2/31May95-0229PM)
	id AA22177; Thu, 20 Jun 1996 11:27:48 -0400
Received: from ccMail by smtpgty.bwi.wec.com
  (IMA Internet Exchange 2.0 Enterprise) id 1C971760; Thu, 20 Jun 96 11:42:46 -0400
Mime-Version: 1.0
Date: Thu, 20 Jun 1996 11:37:50 -0400
Message-Id: <1C971760.1858@smtpgty.bwi.wec.com>
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-)
Subject: Re: [HFSIG:1238] 
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     I'm curious, what would this C program look like?
     
     73s de
     Tony,  KE4ATO


______________________________ Reply Separator _________________________________
Subject: [HFSIG:1238] 
Author:  hfsig@tapr.org at BALT.SMTP
Date:    6/20/96 6:36 AM


     
If you have a sound blaster your best bet (and cheapest) would be to record the 
satilite on disk the play it back to
the DSP. 10 minutes will take about 5MB. You may need make your DSP code more 
independent of the
PC (buffer output etc) or get another PC!
     
Its actually quite simple to write a C program to play the sound file and act as
a dumb terminal at the same time.
=============================
I see. Yes I do have another PC. BTW what is the bandwidth of the DAT tape ? I 
suppose it has now phase
distorsion ie wow & flutter ?
     
danie
     
     

From Robert.Glassey@nmp.nokia.com Thu Jun 20 12:40:16 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA24162 for <hfsig@tapr.org>; Thu, 20 Jun 1996 12:40:12 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id UAA10748; Thu, 20 Jun 1996 20:39:36 +0300
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA297632257; Thu, 20 Jun 1996 20:37:37 +0300
X-Openmail-Hops: 2
Date: Thu, 20 Jun 96 18:36:59 +0100
Message-Id: <H000029201e4bf8e@MHS>
In-Reply-To: <1C971760.1858@smtpgty.bwi.wec.com>
Subject: [HFSIG:1239] Re:
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org, LANIER.R.A-@smtpgty.bwi.wec.com

>> Its actually quite simple to write a C program to play the sound file
>> and act as a dumb terminal at the same time.

>      I'm curious, what would this C program look like?
>      
>      73s de
>      Tony,  KE4ATO

There's libraries available on simtel for the SB stuff. It would look
something like this:

main()
{

soundblaster_reset(); /* also checks for card */

buffer_mem=faralloc(128*1024l); /* 64 k buffer when page aligned */

buffer=[page alignment of buffer_mem pointer ie to get XX00:0000]
/* this is so the DMA doesn't cross a 64K page boundry */

[setup interupt on SB IRQ]

[set DMA parameters - port commands]

[set sound blaster sample rate -port commands]

file=fopen("sat_rec","rb");

[read 32k from file into buffer]

[start SB playing in auto init mode]

quit=0;
buffer_flag=0;
while(!quit)
  {
/* double buffered disk read for SB */
  dma=[read DMA pointer]
  if (dma > 16384) && (buffer_flag==0)
    {
    /* if was lo and now playing hi half, load new low half*/
    [read next 16k to low half of buffer]; buffer_flag=1;
    }
  if (dma < 16384) && (buffer_flag==1)
    {
    /* if was hi and now playing lo half, load new high half*/
    [read next 16k to high half of buffer]; buffer_flag=0;
    }

/* very dumb terminal */  
  if(kbhit())
    {
    ch=getch();
    if(ch==27) quit=1; /* esc quits */
    [ output ch to com port ]
    }
  [if char available at com port] putc(ch);
  }

stop_sb();
remove_sb_interupt();
fclose(file)
farfree(buffer_mem)
}

sb_interupt()
{
[acknoledge SB interupt - sb port commands]
out 20h,20h
}

I'm bound to have forgotten something, and have brushed over many things
but this is roughly how it would look. There's lots of other error and
end of file stuff as well.

To record the sample there's a few simple but good programs on simtel
which will do the trick nicely. Actually there might even be a
background TSR program that will play the soundfile in the background so

you can just run your normal terminal program. Or maybe use a standard
windows player and terminal, that might be even easier!

Cheers,

Rob

From zs6awk@global.co.za  Thu Jun 20 15:03:14 1996
Received: from lin01.global.co.za (lin01.global.co.za [196.3.164.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA29685 for <hfsig@tapr.org>; Thu, 20 Jun 1996 15:03:09 -0500 (CDT)
Received: from anx_116.global.co.za (anx_82.global.co.za [196.3.164.132]) by lin01.global.co.za (8.7.3/8.7.3) with SMTP id WAA06699 for <hfsig@tapr.org>; Thu, 20 Jun 1996 22:01:01 -0200 (GMT)
Message-Id: <199606210001.WAA06699@lin01.global.co.za>
X-Sender: zs6awk@mail.global.co.za
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 20 Jun 1996 22:02:32 +0200
To: hfsig@tapr.org
From: zs6awk@global.co.za (Danie Brynard)
Subject: info on C31 DSK ?

Does anybody have more info on the new TI TMS320C31 DSK ? Like amount of RAM
and release date ? How good is the debugger ie compared to say 56002 OnCE ?

danie zs6awk

From Robert.Glassey@nmp.nokia.com Fri Jun 21 08:59:52 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA11919 for <hfsig@tapr.org>; Fri, 21 Jun 1996 08:59:49 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id QAA22122 for <hfsig@tapr.org>; Fri, 21 Jun 1996 16:59:15 +0300
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA098535435; Fri, 21 Jun 1996 16:57:15 +0300
X-Openmail-Hops: 2
Date: Fri, 21 Jun 96 14:56:54 +0100
Message-Id: <H000029201e58799@MHS>
In-Reply-To: <1C9943C0.1858@smtpgty.bwi.wec.com>
Subject: Re: [HFSIG:1239] Re:
Mime-Version: 1.0
To: hfsig@tapr.org
Content-Type: text/plain; charset=ISO-8859-1; name="Re:"
Content-Transfer-Encoding: 7bit

>      Thanks for the code Rob, I appreciate it. Can this code be
>      compiled under Linux using GCC+?
>      
>      Tony,  KE4ATO

Of course its only pseduo code, but it is intended for a PC under DOS.
Under Linux, you'd be better off using the sound card drivers that
already exist for Linux. Sorry I don't know very much about these, only
that they exist.

PS. I've just notices an error in my pseudo code, I allocated a 64
buffer then only used 32K of it (16K for each half of the bouble buffer)
You only really needed to allocate 32K thus:

  
buffer_mem=faralloc(64*1024l); /* 32 k buffer when page aligned */
     
buffer=[page alignment of buffer_mem pointer ie to get XX00:0000] 
/* this is so the DMA doesn't cross a 64K page boundry */

This defines a page aligned 32K buffer in an alocated block of 64K.

It would have worked before, it just allocated twice as much memory as
required.

Cheers,

Rob

From forrerj@ucs.orst.edu Thu Jun 27 11:30:11 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA05111 for <HFSIG@TAPR.ORG>; Thu, 27 Jun 1996 11:30:10 -0500 (CDT)
Received: from p04.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA27122; Thu, 27 Jun 1996 09:30:02 -0700
Message-Id: <1.5.4.16.19960627173228.344f05c6@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu (Unverified)
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 27 Jun 1996 09:32:28 -0800
To: HFSIG@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Question on orthoganal tone spacing

Hi folks,

HFSIG been quiet lately?

I have a question that I would appreciate some insight - I'm a bit confused.

My multi-channel modulation scheme uses four parallel tones, each modulated
at a rate of 75 symbols per second (bauds). If I understood our earlier
discussion, each tone should fit into a 2*75=150 Hz slot. Why does this not
follow the orthogonal 1/T rule for orthogonal spacing, that would put tones
at 75 Hz spacing, not 150 as above?

To check this out, I looked at the MIL-STD-188 16-tone specifications which
is quite similar, i.e., 75 baud with 110 Hz spacing. I tried this spacing
but experience a substantial amount of inter-channel interference.
Demodulation still works but with a serious performance hit - the recovered
channel constellations are really smeared. However, when I go to the 150
(i.e. 2*T) spacing - the constallations are text-book quality.

So - what am I missing ?


---------------FYI-------------------------------------------------------
A little more of where this is heading: four 75 baud tones with DQPSK
modulation gives 600 bps. Various forms of diversity is possible. The
highest form of diversity is when each channel carries the same information
in DBPSK, in which case the rate is only 75 bps, but at four times diversity. 

It would be possible to do what the Pactor-II folks do and up the DQPSK
(4-DPSK) to 8-DQPSK that would essentially yield 1200 bps. Again, it is
possible to use various forms of diversity. For example, using 8-DQPSK, and
a factor of two diversity, would yield 600 bps. 

The idea is to use an interleaved convolutional code, something along the
lines that Phil have been working on. The waveform is 600 Hz wide at the -50
dB level, and could possibly be squeezed be into the 500 Hz constraint.
However, I do not recommend folks getting ideas of using narrow crystal
filters - severe phase distortion at the filter edges. 

If time allows, I hope to do a show and tell demo of the project at the
HFSIG meeting during the upcoming DCC (September 20-22, Seattle).

I sincerely hope that this effort will lead to a future open-architecture
HF-digital protocol. All specifications will be freely available for those
to implement it. Commercial implementations would be encouraged and I would
be happy to offer consulting services if anyone is interested. HFSIG is
there to encourage development and exchange ideas. 
-----------------------------------------------------------------------------


--Johan, KC7WW  

From forrerj@ucs.orst.edu Thu Jun 27 13:55:36 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA11266 for <HFSIG@TAPR.ORG>; Thu, 27 Jun 1996 13:55:33 -0500 (CDT)
Received: from p02.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA23538; Thu, 27 Jun 1996 11:55:25 -0700
Message-Id: <1.5.4.16.19960627195749.0d3f5f2c@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 27 Jun 1996 11:57:49 -0800
To: HFSIG@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Help communicate/translate in Italian

Hi,

Is there a kind soul out there that can help us communicate with a very keen
and interested Italian gentleman?

I have been contacted several times by this keen individual, and although I
can help myself in several languages, Italian unfortunately is not one of
them - I hate to dissapoint, but I need a bit more than a few hand-waving
gestures explaining how to get started using a DSP modem. 

The gentleman is located in Milan. Any help would be greatly appreciated.

Thanks a lot.

--Johan

From bm@lynx.ve3jf.ampr.org Fri Jun 28 10:30:07 1996
Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA29585 for <hfsig@tapr.org>; Fri, 28 Jun 1996 10:30:00 -0500 (CDT)
Received: (from bm@localhost) by lynx.ve3jf.ampr.org (8.6.12/8.6.12) id PAA01611 for hfsig@tapr.org; Fri, 28 Jun 1996 15:31:17 GMT
From: Barry McLarnon VE3JF <bm@lynx.ve3jf.ampr.org>
Message-Id: <199606281531.PAA01611@lynx.ve3jf.ampr.org>
Subject: Re: [HFSIG:1243] Question on orthoganal tone spacing
To: hfsig@tapr.org
Date: Fri, 28 Jun 1996 15:31:17 +0000 (GMT)
In-Reply-To: <1.5.4.16.19960627173228.344f05c6@ucs.orst.edu> from "Johan Forrer" at Jun 27, 96 11:31:51 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text

> I have a question that I would appreciate some insight - I'm a bit confused.
> 
> My multi-channel modulation scheme uses four parallel tones, each modulated
> at a rate of 75 symbols per second (bauds). If I understood our earlier
> discussion, each tone should fit into a 2*75=150 Hz slot. Why does this not
> follow the orthogonal 1/T rule for orthogonal spacing, that would put tones
> at 75 Hz spacing, not 150 as above?

The 1/T rule does apply here - it *should* work with 75 Hz spacing.
 
> To check this out, I looked at the MIL-STD-188 16-tone specifications which
> is quite similar, i.e., 75 baud with 110 Hz spacing. I tried this spacing
> but experience a substantial amount of inter-channel interference.
> Demodulation still works but with a serious performance hit - the recovered
> channel constellations are really smeared. However, when I go to the 150
> (i.e. 2*T) spacing - the constallations are text-book quality.
> 
> So - what am I missing ?

In the case of MIL-STD-188, there is a "guard interval" of about 4.2 ms
at the beginning of the 13.3 ms symbol interval to reduce ISI caused
by multipath.  The integrate-and-dump (or equivalent) doesn't start
until after the guard interval, so T = 9.1 ms and 1/T = 110 Hz.

If your scheme isn't working at 1/T spacing, it seems like an
implementation issue.  Perhaps you're using some kind of baseband pulse
shaping which is destroying the orthogonality of the tones at minimum
spacing?

Barry

-- 
  Barry McLarnon  VE3JF/VA3TCP   |  Internet: bm@hydra.carleton.ca
  Ottawa Amateur Radio Club      |  AMPRnet:  bm@lynx.ve3jf.ampr.org
  Packet Working Group           |  Web:      http://hydra.carleton.ca

From forrerj@ucs.orst.edu Fri Jun 28 22:30:35 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA28033 for <hfsig@tapr.org>; Fri, 28 Jun 1996 22:30:31 -0500 (CDT)
Received: from p09.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM)
	id AA11728; Fri, 28 Jun 1996 20:30:24 -0700
Message-Id: <1.5.4.16.19960629043259.3667fa2c@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu (Unverified)
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Jun 1996 20:32:59 -0800
To: hfsig@tapr.org
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: Re: [HFSIG:1245] Re: Question on orthoganal tone spacing

Hi Barry,


>
>The 1/T rule does apply here - it *should* work with 75 Hz spacing.
> 
>> To check this out, I looked at the MIL-STD-188 16-tone specifications which
>> is quite similar, i.e., 75 baud with 110 Hz spacing. I tried this spacing
>> but experience a substantial amount of inter-channel interference.
>> Demodulation still works but with a serious performance hit - the recovered
>> channel constellations are really smeared. However, when I go to the 150
>> (i.e. 2*T) spacing - the constallations are text-book quality.
>> 
>> So - what am I missing ?
>
>In the case of MIL-STD-188, there is a "guard interval" of about 4.2 ms
>at the beginning of the 13.3 ms symbol interval to reduce ISI caused
>by multipath.  The integrate-and-dump (or equivalent) doesn't start
>until after the guard interval, so T = 9.1 ms and 1/T = 110 Hz.
>
>If your scheme isn't working at 1/T spacing, it seems like an
>implementation issue.  Perhaps you're using some kind of baseband pulse
>shaping which is destroying the orthogonality of the tones at minimum
>spacing?
>
>Barry
>
>-- 
>  Barry McLarnon  VE3JF/VA3TCP   |  Internet: bm@hydra.carleton.ca
>  Ottawa Amateur Radio Club      |  AMPRnet:  bm@lynx.ve3jf.ampr.org
>  Packet Working Group           |  Web:      http://hydra.carleton.ca
>
>

Thanks for the response - you make a good point. It may well be an
implementation issue as there are many factors involved. 

So ... I did a bit of research to understand things a bit better:

I created a signal like the MIL-STD-188 16-tone. 
The way that this is done is to modulate all the carriers, sum them in one
signal and then time-domain filter the ensamble using a pulse shape that has
a "rounded" edges. The edges of this pulse shape are made up of 1/2 Hamming
rolloff cones that has a duration, the length of the guard zone (2.12 ms).
The main portion of the pulse top then is at unity. 

The resultant signal audibly sounds reasonable, none of those ugly clicking
noises, a kind of a warbling-buzzing sound. My spectrum analyzer showed the
carriers are contained as expected and the noise floor is some 30-40 dB down
from the tone carriers.

Result: yes, indeed, the demodulator demodulates the individual signals OK,
but the recovered constellations are *not* as clean as what I would like to
see. Maybe some more implementation issues that may make some improvement? 

I compared this to my individually-RC pulse-shaped signal waveform. Note
that here I use 2*T channel spacing, which is just slighty more than the
MIL-STD-188 tone spacing
(450 vs 440 Hz). I noted significant differences; The dynamic range between
constellation points are at least an order of magnitude better, and the
spurious levels in the spectrum are at least twice a low. 

Thus I suspect that the RC pulse shaping has brought about a cleaner
emission and also improved the eye opening substantially. I would be as
brave as to say that I have high hopes that the scheme may be usable at 8-DQPSK.

OK so where does this leave us with the issue of orthogonality?

I do suspect that it may be practically impossible to achieve that, i.e.,
having that accuracy between the tone set. It seem to take only a very small
error to distroy the orthogonality to the point where it becomes nearly
useless. This may be why the MIL-STD-188 set also does not use the 1/T
spacing?. From your description above, the effectively space the tones is
110 Hz spacing (based on the 9.09 ms pulse). So we are already removed from
the 1/T orthogonal spacing.

Long story, thanks for your patience, but thought it was worth looking into.

73's

--Johan

From karn@baa01075.slip.digex.net Sat Jun 29 01:32:17 1996
Received: from baa01075.slip.digex.net (root@baa01075.slip.digex.net [204.91.208.66]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA11832 for <hfsig@tapr.org>; Sat, 29 Jun 1996 01:32:09 -0500 (CDT)
Received: (from karn@localhost) by baa01075.slip.digex.net (8.7.4/8.7.3) id BAA00279; Sat, 29 Jun 1996 01:25:41 -0400 (EDT)
Date: Sat, 29 Jun 1996 01:25:41 -0400 (EDT)
From: Phil Karn Jr <karn@baa01075.slip.digex.net>
Message-Id: <199606290525.BAA00279@baa01075.slip.digex.net>
To: hfsig@tapr.org
In-reply-to: <1.5.4.16.19960629043259.3667fa2c@ucs.orst.edu> (message from Johan Forrer on Fri, 28 Jun 1996 22:36:04 -0500 (CDT))
Subject: Re: [HFSIG:1246] Re: Question on orthoganal tone spacing
Reply-To: karn@qualcomm.com

>OK so where does this leave us with the issue of orthogonality?

Johan,

I'm out of town so I don't have access to my textbooks, but I *think*
the issue is whether you're using coherent or noncoherent detection.
With a coherent carrier reference at the receiver, you can use carrier
spacing twice as dense as with noncoherent detection.

Since you are using DQPSK, I assume you're doing noncoherent detection.
That could explain your need for greater tone spacing.

Phil

From bm@lynx.ve3jf.ampr.org Sat Jun 29 11:32:55 1996
Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA01365 for <hfsig@tapr.org>; Sat, 29 Jun 1996 11:32:51 -0500 (CDT)
Received: (from bm@localhost) by lynx.ve3jf.ampr.org (8.6.12/8.6.12) id QAA02843 for hfsig@tapr.org; Sat, 29 Jun 1996 16:34:04 GMT
From: Barry McLarnon VE3JF <bm@lynx.ve3jf.ampr.org>
Message-Id: <199606291634.QAA02843@lynx.ve3jf.ampr.org>
Subject: Re: [HFSIG:1247] Re: Question on orthoganal tone spacing
To: hfsig@tapr.org
Date: Sat, 29 Jun 1996 16:34:04 +0000 (GMT)
In-Reply-To: <199606290525.BAA00279@baa01075.slip.digex.net> from "Phil Karn Jr" at Jun 29, 96 01:44:39 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text

> >OK so where does this leave us with the issue of orthogonality?
> 
> Johan,
> 
> I'm out of town so I don't have access to my textbooks, but I *think*
> the issue is whether you're using coherent or noncoherent detection.
> With a coherent carrier reference at the receiver, you can use carrier
> spacing twice as dense as with noncoherent detection.
> 
> Since you are using DQPSK, I assume you're doing noncoherent detection.
> That could explain your need for greater tone spacing.
> 
> Phil

This is true, but with coherent detection you can achieve a minimum
orthogonal carrier spacing of 1/(2T).  With noncoherent detection, the
minimum spacing is 1/T as previously stated.  A good example of a
practical system using 1/T carrier spacing and noncoherent detection
(DQPSK) is the Eureka 147 Digital Audio Broadcast system.  For Mode 2
DAB, which we use here in Canada at L Band, the parameters are:

Transmitted symbol length T = 312.5 us, composed of:
	Tg = 62.5 us (guard interval)
	Ts = 250 us (symbol length in the demodulator)

Carrier spacing = 1/Ts = 4 KHz

There are 384 carriers, producing an overall bandwidth of 1.536 MHz.

I suspect that Johan's modem may not be performing well with 1/T carrier
spacing because he is using windowing which destroys the orthogonality.
Have you tried using rectangular windowing, Johan?  And, of course, if
you implement a guard time to avoid ISI, you must adjust the carrier
spacing so that the orthogonality is maintained in the demodulator
(spacing of 1/Ts rather than 1/T).

Barry

-- 
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